Re: BUG and Oops while trying to issue a discard to LVM on RAID1 md
On 5 October 2016 at 16:04, Sitsofe Wheeler wrote: > On 4 October 2016 at 07:20, Sitsofe Wheeler wrote: >> On 4 October 2016 at 07:17, Sitsofe Wheeler wrote: >>> While trying to do a discard inside an ESXi 6 VM to an LVM device atop >>> an md RAID1 device composed of two SATA SSDs passed up as a raw disk >>> mappings through a PVSCSI controller, this BUG followed by an Oops was >>> hit: >>> >>> [ 86.902888] [ cut here ] >>> [ 86.904600] kernel BUG at arch/x86/kernel/pci-nommu.c:66! (sent that a bit too soon) On a 4.8.0 kernel the problem seems to have shifted a bit but still results in a lock up: [ 26.208152] [ cut here ] [ 26.208935] kernel BUG at ./include/linux/scatterlist.h:90! [ 26.209799] invalid opcode: [#1] SMP [ 26.210454] Modules linked in: vmw_vsock_vmci_transport vsock sb_edac edac_core intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel raid1 intel_rapl_perf ppdev vmw_balloon pcspkr joydev vmxnet3 acpi_cpufreq tpm_tis tpm_tis_core tpm vmw_vmci fjes shpchp parport_pc parport i2c_piix4 dm_multipath vmwgfx drm_kms_helper ttm drm crc32c_intel serio_raw vmw_pvscsi ata_generic pata_acpi [ 26.216797] CPU: 0 PID: 220 Comm: kworker/0:1H Not tainted 4.8.0-1.vanilla.knurd.1.fc24.x86_64 #1 [ 26.218191] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2014 [ 26.219861] Workqueue: kblockd blk_delay_work [ 26.220570] task: 9608bf30 task.stack: 9608b9d9 [ 26.221505] RIP: 0010:[] [] blk_rq_map_sg+0x317/0x560 [ 26.222812] RSP: 0018:9608b9d93b78 EFLAGS: 00010002 [ 26.223650] RAX: 002e RBX: 0200 RCX: 9608bb71bd00 [ 26.224766] RDX: 0007fc01 RSI: 0002 RDI: 0400 [ 26.225867] RBP: 9608b9d93c00 R08: 9608bec1ca00 R09: [ 26.226992] R10: 9608bb71bd00 R11: 9608bb74d900 R12: 0200 [ 26.228085] R13: 0400 R14: R15: 9608bb71b800 [ 26.229195] FS: () GS:9608bec0() knlGS: [ 26.230509] CS: 0010 DS: ES: CR0: 80050033 [ 26.231442] CR2: 7fe4bc4ea000 CR3: 39cab000 CR4: 001406f0 [ 26.232620] Stack: [ 26.232967] 9608b9d93bd0 9d3f2f1d 9608bb71bd00 01080020 [ 26.234269] 9608bfaade60 9608bf162380 002e [ 26.235558] 04000200 80a6fe96 [ 26.236854] Call Trace: [ 26.237263] [] ? __sg_alloc_table+0x7d/0x160 [ 26.238217] [] scsi_init_sgtable+0x3d/0x70 [ 26.239148] [] scsi_init_io+0x44/0x1c0 [ 26.240013] [] sd_init_command+0x2b2/0xde0 [ 26.240970] [] ? scsi_host_alloc_command+0x4b/0xc0 [ 26.242015] [] scsi_setup_cmnd+0x101/0x160 [ 26.242962] [] scsi_prep_fn+0xf4/0x180 [ 26.243869] [] blk_peek_request+0x16e/0x2b0 [ 26.244836] [] scsi_request_fn+0x3f/0x5f0 [ 26.245756] [] __blk_run_queue+0x33/0x40 [ 26.246636] [] blk_delay_work+0x25/0x40 [ 26.247506] [] process_one_work+0x184/0x430 [ 26.248433] [] worker_thread+0x4e/0x480 [ 26.249311] [] ? process_one_work+0x430/0x430 [ 26.250265] [] ? process_one_work+0x430/0x430 [ 26.251210] [] kthread+0xd8/0xf0 [ 26.251993] [] ret_from_fork+0x1f/0x40 [ 26.252845] [] ? kthread_worker_fn+0x180/0x180 [ 26.253801] Code: c6 41 01 c5 41 29 c0 41 29 c4 44 39 ea 75 c9 41 83 c6 01 45 31 ed eb c0 48 8b 4c 24 10 48 8b 31 83 e6 03 a8 03 0f 84 38 ff ff ff <0f> 0b 48 8b 5c 24 20 4c 89 54 24 30 48 89 df ff 90 c0 00 00 00 [ 26.258363] RIP [] blk_rq_map_sg+0x317/0x560 [ 26.259345] RSP [ 26.259890] ---[ end trace bb376bf807673a6f ]--- [ 26.260678] BUG: unable to handle kernel paging request at 80a6fe96 [ 26.261828] IP: [] __wake_up_common+0x2b/0x80 [ 26.262785] PGD 0 [ 26.263141] Oops: [#2] SMP [ 26.263644] Modules linked in: vmw_vsock_vmci_transport vsock sb_edac edac_core intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel raid1 intel_rapl_perf ppdev vmw_balloon pcspkr joydev vmxnet3 acpi_cpufreq tpm_tis tpm_tis_core tpm vmw_vmci fjes shpchp parport_pc parport i2c_piix4 dm_multipath vmwgfx drm_kms_helper ttm drm crc32c_intel serio_raw vmw_pvscsi ata_generic pata_acpi [ 26.270080] CPU: 0 PID: 220 Comm: kworker/0:1H Tainted: G D 4.8.0-1.vanilla.knurd.1.fc24.x86_64 #1 [ 26.271661] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2014 [ 26.273349] task: 9608bf30 task.stack: 9608b9d9 [ 26.274273] RIP: 0010:[] [] __wake_up_common+0x2b/0x80 [ 26.275621] RSP: 0018:9608b9d93e38 EFLAGS: 00010086 [ 26.276454] RAX: 0282 RBX: 9608b9d93f10 RCX: [ 26.277593] RDX: 80a6fe96 RSI: 0
Re: BUG and Oops while trying to issue a discard to LVM on RAID1 md
On 4 October 2016 at 07:20, Sitsofe Wheeler wrote: > On 4 October 2016 at 07:17, Sitsofe Wheeler wrote: >> While trying to do a discard inside an ESXi 6 VM to an LVM device atop >> an md RAID1 device composed of two SATA SSDs passed up as a raw disk >> mappings through a PVSCSI controller, this BUG followed by an Oops was >> hit: >> >> [ 86.902888] [ cut here ] >> [ 86.904600] kernel BUG at arch/x86/kernel/pci-nommu.c:66! On a 4.8.0 kernel the problem seems to have shifted a bit: -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG and Oops while trying to issue a discard to LVM on RAID1 md
On 4 October 2016 at 07:17, Sitsofe Wheeler wrote: > While trying to do a discard inside an ESXi 6 VM to an LVM device atop > an md RAID1 device composed of two SATA SSDs passed up as a raw disk > mappings through a PVSCSI controller, this BUG followed by an Oops was > hit: > > [ 86.902888] [ cut here ] > [ 86.904600] kernel BUG at arch/x86/kernel/pci-nommu.c:66! > [ 86.906538] invalid opcode: [#1] SMP > [ 86.907991] Modules linked in: vmw_vsock_vmci_transport vsock > sb_edac edac_core intel_powerclamp coretemp crct10dif_pclmul raid1 > crc32_pclmul ppdev ghash_clmulni_intel vmw_balloon joydev > intel_rapl_perf vmxnet3 acpi_cpufreq tpm_tis fjes parport_pc tpm > vmw_vmci parport shpchp i2c_piix4 dm_multipath vmwgfx drm_kms_helper > ttm drm crc32c_intel serio_raw ata_generic vmw_pvscsi pata_acpi > [ 86.914919] CPU: 0 PID: 214 Comm: kworker/0:1H Not tainted > 4.7.5-200.fc24.x86_64 #1 > [ 86.916123] Hardware name: VMware, Inc. VMware Virtual > Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2014 > [ 86.917720] Workqueue: kblockd blk_delay_work > [ 86.918395] task: 88003a65bd00 ti: 88003fb18000 task.ti: > 88003fb18000 > [ 86.919478] RIP: 0010:[] [] > nommu_map_sg+0x91/0xc0 > [ 86.920697] RSP: 0018:88003fb1bc70 EFLAGS: 00010046 > [ 86.921471] RAX: 0200 RBX: 0001 RCX: > 0001 > [ 86.922539] RDX: RSI: 88003f8ca600 RDI: > 88003ce820a0 > [ 86.923611] RBP: 88003fb1bc98 R08: R09: > > [ 86.924692] R10: 88003f053000 R11: 88003c38c900 R12: > 0001 > [ 86.925733] R13: 88003ce820a0 R14: 0001 R15: > 88003f8ca600 > [ 86.926817] FS: () GS:88003ec0() > knlGS: > [ 86.928084] CS: 0010 DS: ES: CR0: 80050033 > [ 86.928958] CR2: 7fc762951dd0 CR3: 3b6f8000 CR4: > 001406f0 > [ 86.930034] Stack: > [ 86.930334] 0001 88003ce820a0 b4c1b1c0 > 0001 > [ 86.931541] 0001 88003fb1bcd8 b4565e87 > 88003f8ca600 > [ 86.932762] 88003f075f80 88003c38c900 88003f944000 > 88003f082c90 > [ 86.933990] Call Trace: > [ 86.934361] [] scsi_dma_map+0x97/0xc0 > [ 86.935122] [] pvscsi_queue+0x4a5/0x860 [vmw_pvscsi] > [ 86.936129] [] ? scsi_test_unit_ready+0x150/0x150 > [ 86.937099] [] scsi_dispatch_cmd+0xdd/0x220 > [ 86.937936] [] scsi_request_fn+0x461/0x5f0 > [ 86.938811] [] ? __switch_to+0x29a/0x4a0 > [ 86.939705] [] __blk_run_queue+0x33/0x40 > [ 86.940504] [] blk_delay_work+0x25/0x40 > [ 86.941308] [] process_one_work+0x184/0x440 > [ 86.942246] [] worker_thread+0x4e/0x480 > [ 86.943054] [] ? process_one_work+0x440/0x440 > [ 86.944033] [] ? process_one_work+0x440/0x440 > [ 86.944961] [] kthread+0xd8/0xf0 > [ 86.945699] [] ret_from_fork+0x1f/0x40 > [ 86.946507] [] ? kthread_worker_fn+0x180/0x180 > [ 86.947479] Code: ff ff ff 85 c0 74 3c 41 8b 47 0c 4c 89 ff 83 c3 > 01 41 89 47 18 e8 10 d1 3b 00 41 39 dc 49 89 c7 74 1e 49 8b 17 48 83 > e2 fc 75 af <0f> 0b be 3f 00 00 00 48 c7 c7 59 51 a2 b4 e8 5c 1f 07 00 > eb 80 > [ 86.951837] RIP [] nommu_map_sg+0x91/0xc0 > [ 86.952728] RSP > [ 86.953238] ---[ end trace 9ce6a81b32bb6ab3 ]--- > [ 86.954013] BUG: unable to handle kernel paging request at ffd8 > [ 86.955145] IP: [] kthread_data+0x10/0x20 > [ 86.956059] PGD 34c09067 PUD 34c0b067 PMD 0 > [ 86.956776] Oops: [#2] SMP > [ 86.957245] Modules linked in: vmw_vsock_vmci_transport vsock > sb_edac edac_core intel_powerclamp coretemp crct10dif_pclmul raid1 > crc32_pclmul ppdev ghash_clmulni_intel vmw_balloon joydev > intel_rapl_perf vmxnet3 acpi_cpufreq tpm_tis fjes parport_pc tpm > vmw_vmci parport shpchp i2c_piix4 dm_multipath vmwgfx drm_kms_helper > ttm drm crc32c_intel serio_raw ata_generic vmw_pvscsi pata_acpi > [ 86.962934] CPU: 0 PID: 214 Comm: kworker/0:1H Tainted: G D > 4.7.5-200.fc24.x86_64 #1 > [ 86.964251] Hardware name: VMware, Inc. VMware Virtual > Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2014 > [ 86.965871] task: 88003a65bd00 ti: 88003fb18000 task.ti: > 88003fb18000 > [ 86.966969] RIP: 0010:[] [] > kthread_data+0x10/0x20 > [ 86.968221] RSP: 0018:88003fb1b940 EFLAGS: 00010002 > [ 86.968978] RAX: RBX: 88003ec18100 RCX: > > [ 86.970043] RDX: 88003e803090 RSI: 88003a65bd80 RDI: > 88003a65bd00 > [ 86.971059] RBP: 88003fb1b940 R08: 88003a65bda8 R09: >
BUG and Oops while trying to issue a discard to LVM on RAID1 md
While trying to do a discard inside an ESXi 6 VM to an LVM device atop an md RAID1 device composed of two SATA SSDs passed up as a raw disk mappings through a PVSCSI controller, this BUG followed by an Oops was hit: [ 86.902888] [ cut here ] [ 86.904600] kernel BUG at arch/x86/kernel/pci-nommu.c:66! [ 86.906538] invalid opcode: [#1] SMP [ 86.907991] Modules linked in: vmw_vsock_vmci_transport vsock sb_edac edac_core intel_powerclamp coretemp crct10dif_pclmul raid1 crc32_pclmul ppdev ghash_clmulni_intel vmw_balloon joydev intel_rapl_perf vmxnet3 acpi_cpufreq tpm_tis fjes parport_pc tpm vmw_vmci parport shpchp i2c_piix4 dm_multipath vmwgfx drm_kms_helper ttm drm crc32c_intel serio_raw ata_generic vmw_pvscsi pata_acpi [ 86.914919] CPU: 0 PID: 214 Comm: kworker/0:1H Not tainted 4.7.5-200.fc24.x86_64 #1 [ 86.916123] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2014 [ 86.917720] Workqueue: kblockd blk_delay_work [ 86.918395] task: 88003a65bd00 ti: 88003fb18000 task.ti: 88003fb18000 [ 86.919478] RIP: 0010:[] [] nommu_map_sg+0x91/0xc0 [ 86.920697] RSP: 0018:88003fb1bc70 EFLAGS: 00010046 [ 86.921471] RAX: 0200 RBX: 0001 RCX: 0001 [ 86.922539] RDX: RSI: 88003f8ca600 RDI: 88003ce820a0 [ 86.923611] RBP: 88003fb1bc98 R08: R09: [ 86.924692] R10: 88003f053000 R11: 88003c38c900 R12: 0001 [ 86.925733] R13: 88003ce820a0 R14: 0001 R15: 88003f8ca600 [ 86.926817] FS: () GS:88003ec0() knlGS: [ 86.928084] CS: 0010 DS: ES: CR0: 80050033 [ 86.928958] CR2: 7fc762951dd0 CR3: 3b6f8000 CR4: 001406f0 [ 86.930034] Stack: [ 86.930334] 0001 88003ce820a0 b4c1b1c0 0001 [ 86.931541] 0001 88003fb1bcd8 b4565e87 88003f8ca600 [ 86.932762] 88003f075f80 88003c38c900 88003f944000 88003f082c90 [ 86.933990] Call Trace: [ 86.934361] [] scsi_dma_map+0x97/0xc0 [ 86.935122] [] pvscsi_queue+0x4a5/0x860 [vmw_pvscsi] [ 86.936129] [] ? scsi_test_unit_ready+0x150/0x150 [ 86.937099] [] scsi_dispatch_cmd+0xdd/0x220 [ 86.937936] [] scsi_request_fn+0x461/0x5f0 [ 86.938811] [] ? __switch_to+0x29a/0x4a0 [ 86.939705] [] __blk_run_queue+0x33/0x40 [ 86.940504] [] blk_delay_work+0x25/0x40 [ 86.941308] [] process_one_work+0x184/0x440 [ 86.942246] [] worker_thread+0x4e/0x480 [ 86.943054] [] ? process_one_work+0x440/0x440 [ 86.944033] [] ? process_one_work+0x440/0x440 [ 86.944961] [] kthread+0xd8/0xf0 [ 86.945699] [] ret_from_fork+0x1f/0x40 [ 86.946507] [] ? kthread_worker_fn+0x180/0x180 [ 86.947479] Code: ff ff ff 85 c0 74 3c 41 8b 47 0c 4c 89 ff 83 c3 01 41 89 47 18 e8 10 d1 3b 00 41 39 dc 49 89 c7 74 1e 49 8b 17 48 83 e2 fc 75 af <0f> 0b be 3f 00 00 00 48 c7 c7 59 51 a2 b4 e8 5c 1f 07 00 eb 80 [ 86.951837] RIP [] nommu_map_sg+0x91/0xc0 [ 86.952728] RSP [ 86.953238] ---[ end trace 9ce6a81b32bb6ab3 ]--- [ 86.954013] BUG: unable to handle kernel paging request at ffd8 [ 86.955145] IP: [] kthread_data+0x10/0x20 [ 86.956059] PGD 34c09067 PUD 34c0b067 PMD 0 [ 86.956776] Oops: [#2] SMP [ 86.957245] Modules linked in: vmw_vsock_vmci_transport vsock sb_edac edac_core intel_powerclamp coretemp crct10dif_pclmul raid1 crc32_pclmul ppdev ghash_clmulni_intel vmw_balloon joydev intel_rapl_perf vmxnet3 acpi_cpufreq tpm_tis fjes parport_pc tpm vmw_vmci parport shpchp i2c_piix4 dm_multipath vmwgfx drm_kms_helper ttm drm crc32c_intel serio_raw ata_generic vmw_pvscsi pata_acpi [ 86.962934] CPU: 0 PID: 214 Comm: kworker/0:1H Tainted: G D 4.7.5-200.fc24.x86_64 #1 [ 86.964251] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2014 [ 86.965871] task: 88003a65bd00 ti: 88003fb18000 task.ti: 88003fb18000 [ 86.966969] RIP: 0010:[] [] kthread_data+0x10/0x20 [ 86.968221] RSP: 0018:88003fb1b940 EFLAGS: 00010002 [ 86.968978] RAX: RBX: 88003ec18100 RCX: [ 86.970043] RDX: 88003e803090 RSI: 88003a65bd80 RDI: 88003a65bd00 [ 86.971059] RBP: 88003fb1b940 R08: 88003a65bda8 R09: [ 86.972105] R10: R11: 0015eb90 R12: 88003a65c350 [ 86.973160] R13: 88003ec18100 R14: 88003a65bd00 R15: 00018100 [ 86.974262] FS: () GS:88003ec0() knlGS: [ 86.975480] CS: 0010 DS: ES: CR0: 80050033 [ 86.976352] CR2: 0028 CR3: 3b6f8000 CR4: 001406f0 [ 86.977517] Stack: [ 86.977843] 88003fb1b950 b40bb23e 88003fb1b9a8 b47e802f [ 86.979065] 00ff88003fb1b9c0
Re: BLKZEROOUT not zeroing md dev on VMDK
On Wed, Jun 15, 2016 at 06:17:37PM +, Arvind Kumar wrote: > It is possibly some race. We saw a WRITE SAME related issue in past > for which Petr sent out a patch but looks like the patch didn't make > it. :( > > https://groups.google.com/forum/#!topic/linux.kernel/1WGDSlyY0y0 Indeed - the investigation you folks did is linked to within the upstream Bugzilla bug (see https://bugzilla.kernel.org/show_bug.cgi?id=118581#c2 ). Hopefully this issue will be resolved but there's still some debate over on http://thread.gmane.org/gmane.linux.kernel/2236800 . The problem is that it is causing real problems in stable kernels (data not being correctly zero'd) today... -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BLKZEROOUT not zeroing md dev on VMDK
On 27 May 2016 at 10:30, Tom Yan wrote: > There seems to be some sort of race condition between > blkdev_issue_zeroout() and the scsi disk driver (disabling write same > after an illegal request). On my UAS drive, sometimes `blkdiscard -z > /dev/sdX` will return right away, even though if I then check > `write_same_max_bytes` it has turned 0. Sometimes it will just write > zero with SCSI WRITE even if `write_same_max_bytes` is 33553920 before > I issue `blkdiscard -z` (`write_same_max_bytes` also turned 0, as > expected). > > Not sure if it is directly related to the case here though. I'm not aware of hitting that particular problem myself directly on the underlying "SCSI" device but the patch on https://patchwork.kernel.org/patch/9137311/ should be able to resolve that issue. Could you test it and follow up on http://permalink.gmane.org/gmane.linux.kernel/2229377 ? I'm hoping more testing reports will lead to the patch being reviewed and accepted sooner rather than later as it's currently stalled... -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BLKZEROOUT not zeroing md dev on VMDK
On 27 May 2016 at 05:18, Darrick J. Wong wrote:
>
> It's possible that the pvscsi device advertised WRITE SAME, but if the device
> sends back ILLEGAL REQUEST then the SCSI disk driver will set
> write_same_max_bytes=0. Subsequent BLKZEROOUT attempts will then issue writes
> of zeroes to the drive.
Thanks for following up on this but that's not what happens on the md
device - you can go on to issue as many BLKZEROOUT requests as you
like but the md disk is never zeroed nor is an error returned.
I filed a bug at https://bugzilla.kernel.org/show_bug.cgi?id=118581
(see https://bugzilla.kernel.org/show_bug.cgi?id=118581#c6 for
alternative reproduction steps that use scsi_debug and can be reworked
to impact device mapper) and Shaohua Li noted that
blkdev_issue_write_same could return 0 even when the disk didn't
support write same (see
https://bugzilla.kernel.org/show_bug.cgi?id=118581#c8 ).
Shaohua went on to create a patch for this ("block: correctly fallback
for zeroout" - https://patchwork.kernel.org/patch/9137311/ ) which has
yet to be reviewed.
--
Sitsofe | http://sucs.org/~sits/
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
BLKZEROOUT not zeroing md dev on VMDK
Hi, With Ubuntu's 4.4.0-22-generic kernel and a Fedora 23 4.6.0-1.vanilla.knurd.1.fc23.x86_64 kernel I've found that the BLKZEROOUT syscall can malfunction and not zero data. When BLKZEROOUT is issued to an MD device atop a PVSCSI controller supplied VMDK from ESXi 6.0 the call returns immediately and with a zero return code. Unfortunately, inspecting the data on the MD device shows that it has not been zeroed and is in fact untouched. The easiest way to see this behaviour is to boot the VM, create an mdadm device atop /dev/sd?, scribble some non-zero value on the disk and then use blkdiscard --zeroout /dev/md??? . If you then inspect the MD disk (e.g. with hexdump) you will still see the old data and using POSIX_FADV_DONTNEED on the MD device doesn't change the outcome. The only clue I've seen is that /sys/block/sd?/queue/write_same_max_bytes starts out being 33553920 but after a WRITE SAME is issued it becomes 0. If the MD device is created after write_same_max_bytes has become 0 on the backing disk then BLKZEROOUT seems to work correctly. -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2
On Wed, Dec 10, 2014 at 11:30:30PM +, KY Srinivasan wrote:
>
> > >
> > > + {"Msft", "Virtual Disk", "1.0", BLIST_TRY_VPD_PAGES},
> > >
> > > Is that version field meaningful or is it safe for us to inquire about
> > > VPD pages without problems on older versions?
> >
> > This version is used in all current Hyper-V hosts: Windows 2008 R2, 2012 and
> > 2012 R2. However it may change in future Windows releases.
>
> The next version of the host will be claiming conformance to SPC-3
Will the version number ("1.0") of Virtual Disks also be changed? Part
of me hopes it will as it will mean certain quirks for virtual disks
will be easier to apply and won't need host version (are you 2008, 2012,
2016) version logic...
--
Sitsofe | http://sucs.org/~sits/
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] scsi:storvsc enable reading from VPD pages on SPC-2
On Wed, Dec 10, 2014 at 12:38:25AM -0800, Long Li wrote: > MSFT targets currently claim SPC-2 compliance while they implement > post SPC-2 features. With this patch we can correctly handle > WRITE_SAME_16 issues. > > This patch fixes an issue where the flag is setup too late in drive > initialization process. Li, is this a fix for the issue I keep whinging about over in https://lkml.org/lkml/2014/10/21/23 ? If is the same issue you may want to CC Martin on this... -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks
On 23 October 2014 02:50, Martin K. Petersen wrote:
>>>>>> "Sitsofe" == Sitsofe Wheeler writes:
>
> Sitsofe> 2. On top of the above, when a disk is "small" (has less than
> Sitsofe>2^32 sectors which is typically < 2 TBytes in size) READ
> Sitsofe>CAPACITY(16) won't be triggered.
>
> static int sd_try_rc16_first(struct scsi_device *sdp)
> {
> if (sdp->host->max_cmd_len < 16)
> return 0;
> if (sdp->try_rc_10_first)
> return 0;
> if (sdp->scsi_level > SCSI_SPC_2)
> return 1;
> if (scsi_device_protection(sdp))
> return 1;
> return 0;
> }
Yes but since SCSI_SPC_2 was being advertised by the Hyper-V virtual
disk (and presumably device protection isn't advertised either) this
function was returning 0. That's why the patch in
https://lkml.org/lkml/2014/10/10/49 added yet another quirk. If if
SPC_3 were correctly advertised on Hyper-V virtual disks would
TRY_VPD_PAGES still be needed to cope correctly with passthrough
disks?
What I didn't realise was that the TRY_VPD_PAGES quirk was purely to
fix WRITE_SAME Hyper-V issues and not to address anything thin
provisioning related. Having said that, why was the TRY_VPD_PAGES
quirk back-ported 3.14 without any users -
https://lkml.org/lkml/2014/9/15/733 ?
--
Sitsofe | http://sucs.org/~sits/
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks
On Sun, Oct 12, 2014 at 01:21:01AM +, KY Srinivasan wrote:
>
> > -Original Message-
> > From: Jeff Leung [mailto:jle...@v10networks.ca]
> > Sent: Saturday, October 11, 2014 1:22 PM
> >
> > > On the current release of Windows (windows 10), we are advertising
> > > SPC3 compliance.
> > > We are ok with declaring compliance to SPC3 in our drivers.
> > If you are going to declare SPC3 compliance in the drivers, are you going to
> > put in checks to ensure that SPC-3 compliance doesn't get accidentally
> > enabled for hypervisors below Win10?
> >
> > I do know for a fact that Ubuntu's kernels already force SPC3 compliance to
> > enable specific features such as TRIM on earlier versions of Hyper-V (Namely
> > Hyper-V 2012 and 2012 R2).
> You are right; Ubuntu has been carrying a patch that was doing just
> this and this has been working without any issues on many earlier
> versions of Windows. (2012 and 2012 R2). On windows 10 we don't need
> any changes in the Linux driver as the host itself is advertising SPC3
> compliance. Based on the testing we have done with Ubuntu, we are
> comfortable picking up that patch.
OK this seems to be the patch currently carried by Ubuntu:
>From ff2c5fa3fa9adf0b919b9425e71a8ba044c31a7d Mon Sep 17 00:00:00 2001
From: Andy Whitcroft
Date: Fri, 13 Sep 2013 17:49:16 +0100
Subject: [PATCH] scsi: hyper-v storsvc switch up to SPC-3
Suggested-By: James Bottomley
Signed-off-by: Andy Whitcroft
---
drivers/scsi/storvsc_drv.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 9969fa1..3903c8a 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -1441,6 +1441,14 @@ static int storvsc_device_configure(struct scsi_device
*sdevice)
sdevice->no_write_same = 1;
+ /*
+* hyper-v lies about its capabilities indicating it is only SPC-2
+* compliant, but actually implements the core SPC-3 features.
+* If we pretend to be SPC-3, we send RC16 which activates trim and
+* will query the appropriate VPD pages to enable trim.
+*/
+ sdevice->scsi_level = SCSI_SPC_3;
+
return 0;
}
--
1.7.9.5
(Downloaded from
http://kernel.ubuntu.com/git?p=jsalisbury/stable/trusty/ubuntu-trusty.git;a=patch;h=ff2c5fa3fa9adf0b919b9425e71a8ba044c31a7d
).
I think it's unwise to override the scsi_level at this particular point
because you are going to do it for ALL Hyper-V "disks" (perhaps all
Hyper-V SCSI devices?)...
Here's the SCSI inquiry information reported by a USB 2 hard disk being
passed passed-through by one of my 2012 R2 hosts:
# sg_inq /dev/sdc
standard INQUIRY:
PQual=0 Device_type=0 RMB=0 version=0x02 [SCSI-2]
[AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=1
SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0]
EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=0 Sync=0 Linked=0 [TranDis=0] CmdQue=0
length=36 (0x24) Peripheral device type: disk
Vendor identification: MDT MD50
Product identification: 00AAKS-00TMA0
Product revision level:
Is it OK to replace a scsi_level of SCSI-2 with SCSI_SPC_3? Additionally
is it also OK to force SCSI_SPC_3 on Hyper-V 2008?
> > > NryزXvؖ){nlj{zX}zj:v zZzf~zwڢ)jyA
> > >
> > > i
> N?r??yb?X??ǧv?^?){.n?+{zX????ܨ}???Ơz?&j:+v???zZ+??+zf???h???~i???z? ?w?&?)ߢf??^jǫy?m??@A?a???
> 0??h???i
^^^ Where do these characters come from? I've occasionally seen them on
emails from other Microsoft folks posting to LKML too...
--
Sitsofe | http://sucs.org/~sits/
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] scsi: add try_rc16 blacklist flag
On Tue, Oct 14, 2014 at 09:08:28PM -0400, Martin K. Petersen wrote: > >>>>> "Sitsofe" == Sitsofe Wheeler writes: > > Sitsofe> Microsoft Hyper-V virtual disks currently only claim SPC-2 > Sitsofe> compliance causing the kernel skip checks for features such as > Sitsofe> thin provisioning even though the virtual disk advertises them. > > Last time around we identified this as a problem with Microsoft's > interpretation of the T10 SBC spec. And they promised that they are > going to fix that. OK but if we were happy to wait for Microsoft to fix the problem on the host why were the (broken and incomplete) BLIST_SKIP_VPD_PAGES patches committed to 3.17 rather than withdrawn? What's going to be done about those patches now? -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks
On Tue, Oct 14, 2014 at 09:06:37PM -0400, Martin K. Petersen wrote:
> >>>>> "Sitsofe" == Sitsofe Wheeler writes:
>
> Sitsofe> A previous patch attempted to add a quirk to workaround this
> Sitsofe> but the quirk was only enabled after the features had been
> Sitsofe> scanned for, wouldn't work for "small" disks
>
> What does that mean, exactly?
It means:
1. The committed patches never worked because the running of the code to
test whether the quirk should be enabled happened after the probing code
the quirk would have affected ran. So roughly:
bflag = 0;
if (feature || bflag) {
do_stuff();
}
if (matching_dev) {
bflag = 1; // Too late...
}
See https://lkml.org/lkml/2014/7/23/615 for prior details.
2. On top of the above, when a disk is "small" (has less than 2^32
sectors which is typically < 2 TBytes in size) READ CAPACITY(16) won't
be triggered. If READ CAPACITY(16) isn't triggered then the lbpme bytes
won't be checked, thin provisioning will never be enabled and the
committed patch would doubly not work for such disks.
Apologies for the delay in replying.
--
Sitsofe | http://sucs.org/~sits/
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] scsi: Use try_rc16 and try_vpd_pages quirks on Hyper-V virtual disks
Microsoft Hyper-V virtual disks currently only claim SPC-2 compliance causing
feature tests not to be run (even though those features are correctly announced
elsewhere). Make Hyper-V virtual disks quirk past READ CAPACITY(16) and VPD
page guards so appropriate tests are performed.
This only impacts Hyper-V's VHD/VHDX virtual disks and not passthrough devices.
Signed-off-by: Sitsofe Wheeler
---
drivers/scsi/scsi_devinfo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index 49014a1..3eadcb1 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -210,6 +210,7 @@ static struct {
{"Medion", "Flash XL MMC/SD", "2.6D", BLIST_FORCELUN},
{"MegaRAID", "LD", NULL, BLIST_FORCELUN},
{"MICROP", "4110", NULL, BLIST_NOTQ},
+ {"Msft", "Virtual Disk", "1.0", BLIST_TRY_VPD_PAGES | BLIST_TRY_RC16},
{"MYLEX", "DACARMRB", "*", BLIST_REPORTLUN2},
{"nCipher", "Fastness Crypto", NULL, BLIST_FORCELUN},
{"NAKAMICH", "MJ-4.8S", NULL, BLIST_FORCELUN | BLIST_SINGLELUN},
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] scsi: add try_rc16 blacklist flag
Microsoft Hyper-V virtual disks currently only claim SPC-2 compliance causing
the kernel skip checks for features such as thin provisioning even though the
virtual disk advertises them.
Add a blacklist flag that can allow such devices to quirk past READ
CAPACITY(16) guards.
Signed-off-by: Sitsofe Wheeler
---
drivers/scsi/scsi_scan.c| 3 +++
drivers/scsi/sd.c | 3 +++
include/scsi/scsi_device.h | 1 +
include/scsi/scsi_devinfo.h | 1 +
4 files changed, 8 insertions(+)
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index ba3f1e8..d3f6267 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -962,6 +962,9 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned
char *inq_result,
else if (*bflags & BLIST_SKIP_VPD_PAGES)
sdev->skip_vpd_pages = 1;
+ if (*bflags & BLIST_TRY_RC16)
+ sdev->try_rc16 = 1;
+
transport_configure_device(&sdev->sdev_gendev);
if (sdev->host->hostt->slave_configure) {
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 0cb5c9f..0ccf372 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2143,6 +2143,9 @@ static int sd_try_rc16_first(struct scsi_device *sdp)
return 0;
if (sdp->scsi_level > SCSI_SPC_2)
return 1;
+ if (sdp->try_rc16) {
+ return 1;
+ }
if (scsi_device_protection(sdp))
return 1;
return 0;
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 27ecee7..d6e2bd8 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -155,6 +155,7 @@ struct scsi_device {
unsigned skip_ms_page_3f:1; /* do not use MODE SENSE page 0x3f */
unsigned skip_vpd_pages:1; /* do not read VPD pages */
unsigned try_vpd_pages:1; /* attempt to read VPD pages */
+ unsigned try_rc16:1;/* attempt READ CAPACITY(16) */
unsigned use_192_bytes_for_3f:1; /* ask for 192 bytes from page 0x3f */
unsigned no_start_on_add:1; /* do not issue start on add */
unsigned allow_restart:1; /* issue START_UNIT in error handler */
diff --git a/include/scsi/scsi_devinfo.h b/include/scsi/scsi_devinfo.h
index 183eaab..9431f5e 100644
--- a/include/scsi/scsi_devinfo.h
+++ b/include/scsi/scsi_devinfo.h
@@ -36,5 +36,6 @@
for sequential scan */
#define BLIST_TRY_VPD_PAGES0x1000 /* Attempt to read VPD pages */
#define BLIST_NO_RSOC 0x2000 /* don't try to issue RSOC */
+#define BLIST_TRY_RC16 0x4000 /* Attempt READ CAPACITY(16) */
#endif
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] Revert "Drivers: add blist flags"
This reverts commit f3cfabce7a2e92564d380de3aad4b43901fb7ae6 (Drivers: add blist flags) as it does not enable thin provisioning for my Hyper-V 2012 R2 virtual disks. Signed-off-by: Sitsofe Wheeler --- drivers/scsi/storvsc_drv.c | 10 -- 1 file changed, 10 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index 733e5f7..2cc094e 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -327,8 +327,6 @@ MODULE_PARM_DESC(storvsc_ringbuffer_size, "Ring buffer size (bytes)"); */ static int storvsc_timeout = 180; -static int msft_blist_flags = BLIST_TRY_VPD_PAGES; - #define STORVSC_MAX_IO_REQUESTS200 static void storvsc_on_channel_callback(void *context); @@ -1439,14 +1437,6 @@ static int storvsc_device_configure(struct scsi_device *sdevice) sdevice->no_write_same = 1; - /* -* Add blist flags to permit the reading of the VPD pages even when -* the target may claim SPC-2 compliance. MSFT targets currently -* claim SPC-2 compliance while they implement post SPC-2 features. -* With this patch we can correctly handle WRITE_SAME_16 issues. -*/ - sdevice->sdev_bflags |= msft_blist_flags; - return 0; } -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] scsi: Add Hyper-V logical block provisioning quirks
Microsoft Hyper-V virtual disks currently only claim SPC-2 compliance even though they implement post SPC-2 features (such as thin provisioning) which means the Linux kernel does not go on to test for those features even though they are advertised. A previous patch attempted to add a quirk to workaround this but the quirk was only enabled after the features had been scanned for, wouldn't work for "small" disks and would quirk on all Hyper-V SCSI devices (e.g. passthrough disks). The new patches partially revert the previous effort, add the quirk in a more traditional manner to only Hyper-V virtual disks and work on small virtual disks. Sitsofe Wheeler (3): Revert "Drivers: add blist flags" scsi: add try_rc16 blacklist flag scsi: Use try_rc16 and try_vpd_pages quirks on Hyper-V virtual disks drivers/scsi/scsi_devinfo.c | 1 + drivers/scsi/scsi_scan.c| 3 +++ drivers/scsi/sd.c | 3 +++ drivers/scsi/storvsc_drv.c | 10 -- include/scsi/scsi_device.h | 1 + include/scsi/scsi_devinfo.h | 1 + 6 files changed, 9 insertions(+), 10 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Drivers: scsi: storvsc: Get rid of warning messages
On Thu, Sep 04, 2014 at 10:40:14PM -0700, Christoph Hellwig wrote: > Looks good to me. > > Olaf, Hannes - can I get another review for this (and the older hyperv > scanning patch set)? I agree this looks useful because on a 59753a805499f1ffbca4ac0a24b3dff67bf1 3.17rc2 kernel with 92578ea Drivers: net: hyperv: Cleanup select queue 7e1ea8c Add documentation for HV_STATUS_INVALID_ALIGNMENT. cecd44d BUG: unable to handle kernel paging request at 8801f5bc7cbb (netvsc_select_queue) 9c6196f Drivers: hv: vmbus: Properly protect calls to smp_processor_id() 2590142 Drivers: hv: vmbus: Cleanup hv_post_message() cd97ae9 Drivers: hv: vmbus: Cleanup vmbus_close_internal() ff08f61 Drivers: hv: vmbus: Fix a bug in vmbus_open() 2f8915e Drivers: hv: vmbus: Cleanup vmbus_establish_gpadl() 6940bd6 Drivers: hv: vmbus: Cleanup vmbus_teardown_gpadl() b022b1b Drivers: hv: vmbus: Cleanup vmbus_post_msg() but without this particular patch applied it is possible for a lot of hv_storvsc vmbus_0_5 messages to be produced while running a command like fio --filename /dev/sdg --ioengine=libaio --iodepth=8 --name=go --rw=randwrite --bs=4k --runtime=10m --time_based=1 --direct=1 and repeatedly removing/re-adding/changing the VHDX backing /dev/sdg from the Linux Hyper-V guest: Sep 05 07:09:57 a kernel: scsi 1:0:1:0: scsi scan: INQUIRY result too short (5), using 36 Sep 05 07:09:57 a kernel: scsi 1:0:1:1: scsi scan: INQUIRY result too short (5), using 36 Sep 05 07:09:57 a kernel: sd 1:0:0:0: [sdf] Synchronizing SCSI cache Sep 05 07:09:57 a kernel: hv_storvsc vmbus_0_5: cmd 0x35 scsi status 0x0 srb status 0x20 Sep 05 07:09:58 a kernel: scsi 1:0:0:0: Direct-Access Msft Virtual Disk 1.0 PQ: 0 ANSI: 4 Sep 05 07:09:58 a kernel: sd 1:0:0:0: [sdf] 2097152 512-byte logical blocks: (1.07 GB/1.00 GiB) Sep 05 07:09:58 a kernel: sd 1:0:0:0: Attached scsi generic sg5 type 0 Sep 05 07:09:58 a kernel: scsi 1:0:1:0: scsi scan: INQUIRY result too short (5), using 36 Sep 05 07:09:58 a kernel: sd 1:0:0:0: [sdf] Write Protect is off Sep 05 07:09:58 a kernel: sd 1:0:0:0: [sdf] Mode Sense: 0f 00 00 00 Sep 05 07:09:58 a kernel: sd 1:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 05 07:09:58 a kernel: sdf: unknown partition table Sep 05 07:09:58 a kernel: scsi 1:0:1:1: scsi scan: INQUIRY result too short (5), using 36 Sep 05 07:09:58 a kernel: sd 1:0:0:0: [sdf] Attached SCSI disk Sep 05 07:09:58 a kernel: md: bind Sep 05 07:09:58 a kernel: md126: detected capacity change from 0 to 1069547520 Sep 05 07:09:58 a kernel: md126: unknown partition table Sep 05 07:09:58 a systemd[1]: Starting LVM2 PV scan on device 9:126... Sep 05 07:09:58 a pvscan[788]: 0 logical volume(s) in volume group "PoolDelete" now active Sep 05 07:09:58 a systemd[1]: Started LVM2 PV scan on device 9:126. Sep 05 07:10:01 a systemd[1]: Starting Session 2 of user root. Sep 05 07:10:01 a systemd[1]: Started Session 2 of user root. Sep 05 07:10:01 a CROND[793]: (root) CMD (/usr/lib64/sa/sa1 1 1) Sep 05 07:10:02 a systemd[673]: Time has been changed Sep 05 07:10:02 a systemd[1]: Time has been changed Sep 05 07:10:07 a systemd[1]: Time has been changed Sep 05 07:10:07 a systemd[673]: Time has been changed Sep 05 07:10:12 a systemd[673]: Time has been changed Sep 05 07:10:12 a systemd[1]: Time has been changed Sep 05 07:10:16 a kernel: scsi 1:0:1:0: scsi scan: INQUIRY result too short (5), using 36 Sep 05 07:10:16 a kernel: scsi 1:0:1:1: scsi scan: INQUIRY result too short (5), using 36 Sep 05 07:10:17 a kernel: scsi 1:0:1:0: scsi scan: INQUIRY result too short (5), using 36 Sep 05 07:10:17 a kernel: scsi 1:0:1:1: scsi scan: INQUIRY result too short (5), using 36 Sep 05 07:10:17 a systemd[1]: Time has been changed Sep 05 07:10:17 a systemd[673]: Time has been changed Sep 05 07:10:22 a systemd[673]: Time has been changed Sep 05 07:10:22 a systemd[1]: Time has been changed Sep 05 07:10:27 a systemd[1]: Time has been changed Sep 05 07:10:27 a systemd[673]: Time has been changed Sep 05 07:10:32 a systemd[673]: Time has been changed Sep 05 07:10:32 a systemd[1]: Time has been changed Sep 05 07:10:37 a systemd[1]: Time has been changed Sep 05 07:10:37 a systemd[673]: Time has been changed Sep 05 07:10:42 a systemd[673]: Time has been changed Sep 05 07:10:42 a systemd[1]: Time has been changed Sep 05 07:10:47 a systemd[1]: Time has been changed Sep 05 07:10:47 a systemd[673]: Time has been changed Sep 05 07:10:51 a kernel: scsi 1:0:1:0: scsi scan: INQUIRY result too short (5), using 36 Sep 05 07:10:53 a kernel: hv_storvsc vmbus_0_5: cmd 0x2a scsi status 0x0 srb status 0x20 Sep 05 07:10:53 a kernel: hv_storvsc vmbus_0_5: cmd 0x2a scsi status 0x0 srb status 0x20 Sep 05 07:10:53 a kernel: hv_storvsc vmbus_0_5: cmd 0x2a scsi status 0x0 srb status 0x20 [Message is repeated] Sep 05 07:10:54 a kernel: hv_storvsc vmbus_0_5: cmd 0x2a scsi status 0x0 srb status 0x20 Sep 05 07:10:54 a kernel: hv_storvsc vmbus_0_5: cmd 0x2a scsi status
Re: [PATCH 1/1] Drivers: scsi: storvsc: Add blist flags
On Thu, Jul 24, 2014 at 07:40:36AM +0200, Hannes Reinecke wrote:
> On 07/22/2014 01:06 AM, K. Y. Srinivasan wrote:
> >Add blist flags to permit the reading of the VPD pages even when
> >the target may claim SPC-2 compliance. MSFT targets currently
> >claim SPC-2 compliance while they implement post SPC-2 features.
> >With this patch we can correctly handle WRITE_SAME_16 issues.
> >
> >Signed-off-by: K. Y. Srinivasan
> >
> Reviewed-by: Hannes Reinecke
On Wed, Jul 23, 2014 at 09:13:41PM +0100, Sitsofe Wheeler wrote:
> On Wed, Jul 23, 2014 at 07:15:58AM -0700, Christoph Hellwig wrote:
> > On Wed, Jul 23, 2014 at 03:10:28PM +0100, Sitsofe Wheeler wrote:
> > > I'm not sure this alone will work - won't sdev_bflags/bflags have
> > > already been built at this point?
> >
> > They've been built up, but we can still or new values into it. It looks
> > fine to me from review, but if you can test it on an actualy hypverv
> > setup that would be valueable feedback.
>
> The previous patches didn't work for me with a Windows 2012 R2 host with a
> 3.16.0-rc6.x86_64-00076-g2f7d2ec-dirty guest. After applying
> https://patchwork.kernel.org/patch/4541201 (which needed a small fixup) and
> https://patchwork.kernel.org/patch/4598601 and the attached debugging output
I've tested f3cfabce7a2e92564d380de3aad4b43901fb7ae6 (Drivers: add blist
flags) from the drivers-for-3.17 branch of scsi-queue
(http://git.infradead.org/users/hch/scsi-queue.git/commit/f3cfabce7a2e92564d380de3aad4b43901fb7ae6
) and this patch still doesn't appear to work (thin provisioning on
Hyper-V's Virtual Disks is not enabled):
# sg_inq /dev/sda
standard INQUIRY:
PQual=0 Device_type=0 RMB=0 version=0x04 [SPC-2]
[AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2
SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0]
EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=0 Sync=0 Linked=0 [TranDis=0] CmdQue=1
length=36 (0x24) Peripheral device type: disk
Vendor identification: Msft
Product identification: Virtual Disk
Product revision level: 1.0
# sg_vpd -p lbpv /dev/sda
Logical block provisioning VPD page (SBC):
Unmap command supported (LBPU): 1
Write same (16) with unmap bit supported (LBWS): 0
Write same (10) with unmap bit supported (LBWS10): 0
Logical block provisioning read zeros (LBPRZ): 0
Anchored LBAs supported (ANC_SUP): 0
Threshold exponent: 1
Descriptor present (DP): 0
Provisioning type: 2
grep . /sys/block/sd*/device/scsi_disk/*/{thin,prov,rotat,device/model}* | sort
/sys/block/sda/device/scsi_disk/0:0:0:0/device/model:Virtual Disk
/sys/block/sda/device/scsi_disk/0:0:0:0/provisioning_mode:full
/sys/block/sda/device/scsi_disk/0:0:0:0/thin_provisioning:0
/sys/block/sdb/device/scsi_disk/1:0:0:0/device/model:Virtual Disk
/sys/block/sdb/device/scsi_disk/1:0:0:0/provisioning_mode:full
/sys/block/sdb/device/scsi_disk/1:0:0:0/thin_provisioning:0
/sys/block/sdc/device/scsi_disk/1:0:0:2/device/model:00AAKS-00TMA0
/sys/block/sdc/device/scsi_disk/1:0:0:2/provisioning_mode:full
/sys/block/sdc/device/scsi_disk/1:0:0:2/thin_provisioning:0
/sys/block/sdd/device/scsi_disk/1:0:0:1/device/model:SSD S510 120GB
/sys/block/sdd/device/scsi_disk/1:0:0:1/provisioning_mode:full
/sys/block/sdd/device/scsi_disk/1:0:0:1/thin_provisioning:0
/sys/block/sde/device/scsi_disk/1:0:0:3/device/model:Virtual Disk
/sys/block/sde/device/scsi_disk/1:0:0:3/provisioning_mode:full
/sys/block/sde/device/scsi_disk/1:0:0:3/thin_provisioning:0
/sys/block/sdf/device/scsi_disk/1:0:0:4/device/model:ST1000DM003-9YN1
/sys/block/sdf/device/scsi_disk/1:0:0:4/provisioning_mode:full
/sys/block/sdf/device/scsi_disk/1:0:0:4/thin_provisioning:0
At least the virtual disks should have thin_provisioning... I was also
expecting the passthrough SSD to be reported as non-rotational with this patch:
# sg_inq /dev/sdd
standard INQUIRY:
PQual=0 Device_type=0 RMB=0 version=0x00 [no conformance claimed]
[AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2
SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0]
EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0
[RelAdr=0] WBus16=0 Sync=0 Linked=0 [TranDis=0] CmdQue=1
[SPI: Clocking=0x0 QAS=0 IUS=0]
length=60 (0x3c) Peripheral device type: disk
Vendor identification: ADATA
Product identification: SSD S510 120GB
Product revision level: 5.2.
Unit serial number: 0320511550032076
# sg_vpd -p bdc /dev/sdd
Block device characteristics VPD page (SBC):
Non-rotating medium (e.g. solid state)
Product type: Not specified
WABEREQ=0
WACEREQ=0
Nominal form factor not reported
FUAB=0
VBULS=0
# grep -H . /sys/block/sdd/queue/rot*
/sys/block/sdd/queue/rotational:1
--
Sitsofe | http://sucs.org/~sits/
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] [SCSI] storvsc: Add Hyper-V logical block provisioning tests
On Thu, Jul 24, 2014 at 02:09:11PM +, James Bottomley wrote: > On Thu, 2014-07-24 at 08:56 +0100, Sitsofe Wheeler wrote: > > Microsoft Hyper-V targets currently only claim SPC-2 compliance / no > > compliance indicated even though they implement post SPC-2 features > > which means those features are not tested for. Add a blacklist flag to > > Hyper-V devices that forces said testing. > > This description is misleading: you don't force the test now, you force > the driver to send unmap commands down to the device. I disagree - UNMAP will only be used if the vpd pages say that UNMAP is supported by the device. I've added two hard disks (one SATA, one on USB) to the VM and here's the debug output with all three patches applied and some extra logging: sd 1:0:0:4: [sdc] Entered read_capacity_16 sd 1:0:0:4: [sdc] Past illegal req sd 1:0:0:4: [sdc] Protection check sd 1:0:0:4: [sdc] Got past protection check sd 1:0:0:4: [sdc] Checking LBPME sd 1:0:0:4: [sdc] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB) sd 1:0:0:4: [sdc] 4096-byte physical blocks sd 1:0:0:4: [sdc] sd_revalidate_disk: Extended inquiry check... sd 1:0:0:4: [sdc] sd_revalidate_disk: Performing extended inquiries sd 1:0:0:4: [sdc] sd_read_block_provisioning: Entered, lbmpe: 0 sd 1:0:0:4: [sdc] sd_read_block_provisioning: Passed lbmpe test sd 1:0:0:4: [sdc] Entered block limits sd 1:0:0:4: [sdc] Started block limits sd 1:0:0:4: [sdc] 0x3c... sd 1:0:0:4: [sdc] Write Protect is off sd 1:0:0:4: [sdc] Mode Sense: 0f 00 00 00 sd 1:0:0:2: [sdd] Entered read_capacity_16 sd 1:0:0:4: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 1:0:0:2: [sdd] 976773168 512-byte logical blocks: (500 GB/465 GiB) sd 1:0:0:4: [sdc] Entered read_capacity_16 sd 1:0:0:2: [sdd] sd_revalidate_disk: Extended inquiry check... sd 1:0:0:2: [sdd] sd_revalidate_disk: Performing extended inquiries sd 1:0:0:2: [sdd] sd_read_block_provisioning: Entered, lbmpe: 0 sd 1:0:0:2: [sdd] sd_read_block_provisioning: Passed lbmpe test sd 1:0:0:4: [sdc] Past illegal req sd 1:0:0:4: [sdc] Protection check sd 1:0:0:4: [sdc] Got past protection check sd 1:0:0:4: [sdc] Checking LBPME sd 1:0:0:2: [sdd] Entered block limits sd 1:0:0:4: [sdc] sd_revalidate_disk: Extended inquiry check... sd 1:0:0:4: [sdc] sd_revalidate_disk: Performing extended inquiries sd 1:0:0:4: [sdc] sd_read_block_provisioning: Entered, lbmpe: 0 sd 1:0:0:4: [sdc] sd_read_block_provisioning: Passed lbmpe test sd 1:0:0:4: [sdc] Entered block limits sd 1:0:0:4: [sdc] Started block limits sd 1:0:0:4: [sdc] 0x3c... sd 1:0:0:2: [sdd] Write Protect is off sd 1:0:0:2: [sdd] Mode Sense: 0f 00 00 00 sd 1:0:0:2: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sd 1:0:0:2: [sdd] Entered read_capacity_16 sd 1:0:0:2: [sdd] sd_revalidate_disk: Extended inquiry check... sd 1:0:0:2: [sdd] sd_revalidate_disk: Performing extended inquiries sd 1:0:0:2: [sdd] sd_read_block_provisioning: Entered, lbmpe: 0 sd 1:0:0:2: [sdd] sd_read_block_provisioning: Passed lbmpe test sd 1:0:0:2: [sdd] Entered block limits sdd: unknown partition table sd 1:0:0:2: [sdd] Entered read_capacity_16 sd 1:0:0:2: [sdd] sd_revalidate_disk: Extended inquiry check... sd 1:0:0:2: [sdd] sd_revalidate_disk: Performing extended inquiries sd 1:0:0:2: [sdd] sd_read_block_provisioning: Entered, lbmpe: 0 sd 1:0:0:2: [sdd] sd_read_block_provisioning: Passed lbmpe test sd 1:0:0:2: [sdd] Entered block limits sd 1:0:0:2: [sdd] Attached SCSI disk sdc: sdc1 sdc2 sd 1:0:0:4: [sdc] Entered read_capacity_16 sd 1:0:0:4: [sdc] Past illegal req sd 1:0:0:4: [sdc] Protection check sd 1:0:0:4: [sdc] Got past protection check sd 1:0:0:4: [sdc] Checking LBPME sd 1:0:0:4: [sdc] sd_revalidate_disk: Extended inquiry check... sd 1:0:0:4: [sdc] sd_revalidate_disk: Performing extended inquiries sd 1:0:0:4: [sdc] sd_read_block_provisioning: Entered, lbmpe: 0 sd 1:0:0:4: [sdc] sd_read_block_provisioning: Passed lbmpe test sd 1:0:0:4: [sdc] Entered block limits sd 1:0:0:4: [sdc] Started block limits sd 1:0:0:4: [sdc] 0x3c... sd 1:0:0:4: [sdc] Attached SCSI disk Both /sys/block/sdc/device/scsi_disk/1\:0\:0\:4/thin_provisioning and cat /sys/block/sdd/device/scsi_disk/1\:0\:0\:2/thin_provisioning return 0. A Hyper-V VHDX disk had output like this: sd 0:0:0:0: [sda] Entered read_capacity_16 sd 0:0:0:0: [sda] Past illegal req sd 0:0:0:0: [sda] Protection check sd 0:0:0:0: [sda] Got past protection check sd 0:0:0:0: [sda] Checking LBPME sd 0:0:0:0: [sda] LBPME OK! sd 0:0:0:0: [sda] Discard mode: 2 sd 0:0:0:0: [sda] 8388608 512-byte logical blocks: (4.29 GB/4.00 GiB) sd 0:0:0:0: [sda] sd_revalidate_disk: Extended inquiry check... sd 0:0:0:0: [sda] sd_revalidate_disk: Performing extended inquiries sd 0:0:0:0: [sda] sd_read_block_provisioning: Entered, lbmpe: 1 sd 0:0:0:0: [sda] sd_read_block_provisioning: Passed lbmpe test sd 0:0:0:0: [sda] sd_read_block_provisioning: Setting block p
Re: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests
On Thu, Jul 24, 2014 at 08:35:13AM -0700, Christoph Hellwig wrote: > On Thu, Jul 24, 2014 at 08:34:19AM -0700, Christoph Hellwig wrote: > > I agree - I'd like to pull in KY's simple fix as soon as I get a second > > review for it. > > Ok, looks like I just got that from Hannes. Let's see if there's more > to be done for the pass through case, but I'd rather wait for the next > window for that. There's nothing Linux can do for today's Hyper-V passthrough wrt to automatically turning on discard on my SATA SSD. Martin explained that vendors often disable UNMAP/WRITE SAME to DSM TRIM translation on purpose and/or have explicit device whitelists/blacklists for those devices they want to support. It could be that Microsoft are doing something similar (although it might be interesting to know how a Windows 2012 guest on Hyper-V handles things). -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests
On Thu, Jul 24, 2014 at 09:54:24AM -0400, Martin K. Petersen wrote: > >>>>> "Sitsofe" == Sitsofe Wheeler writes: > > Sitsofe> Fix incorrectly named variable. Some block devices (such as > Sitsofe> Hyper-V passthrough SSDs) support logical block provisioning > Sitsofe> (e.g. via UNMAP) but don't set lbpme thus disabling discard. > > The fix for an SSD that is known to support LBP but which does not claim > support for it is to use: > > echo unmap > /sys/class/scsi_disk/foo/provisioning_mode > > I'm very much against short-circuiting the LBP logic in a passthrough > driver because then we might end up in the exact situation we were > trying to avoid with this patch series. Namely sending down commands > unsupported by the target device. > > This kind of thing really needs to be a sysadmin decision and can be > handled with a udev rule. The problem is that the SSD _does_ claim to support it. Here are the results of booting Linux directly on the host hardware and looking at the device directly with a 3.10.35 kernel: root@sysresccd /root % uname -a Linux sysresccd 3.10.35-std420-amd64 #2 SMP Wed Apr 2 18:31:51 UTC 2014 x86_64 Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz GenuineIntel GNU/Linux root@sysresccd /root % sg_vpd -p lbpv /dev/sdb root@sysresccd /root % sg_inq /dev/sdb standard INQUIRY: PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0] EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0] WBus16=0 Sync=0 Linked=0 [TranDis=0] CmdQue=0 [SPI: Clocking=0x0 QAS=0 IUS=0] length=96 (0x60) Peripheral device type: disk Vendor identification: ATA Product identification: ADATA SSD S510 1 Product revision level: 5.2. Unit serial number: 0320511550032076 root@sysresccd /root % sg_readcap -l /dev/sdb Read Capacity results: Protection: prot_en=0, p_type=0, p_i_exponent=0 Logical block provisioning: lbpme=1, lbprz=0 Last logical block address=234441647 (0xdf94baf), Number of logical blocks=234441648 Logical block length=512 bytes Logical blocks per physical block exponent=0 Lowest aligned logical block address=0 Hence: Device size: 120034123776 bytes, 114473.5 MiB, 120.03 GB Logical block provisioning VPD page (SBC): Unmap command supported (LBPU): 0 Write same (16) with unmap bit supported (LBWS): 1 Write same (10) with unmap bit supported (LBWS10): 0 Logical block provisioning read zeros (LBPRZ): 0 Anchored LBAs supported (ANC_SUP): 0 Threshold exponent: 0 Descriptor present (DP): 0 Provisioning type: 0 root@sysresccd /root % sg_vpd -p bl /dev/sdb Block limits VPD page (SBC): Write same no zero (WSNZ): 0 Maximum compare and write length: 0 blocks Optimal transfer length granularity: 1 blocks Maximum transfer length: 0 blocks Optimal transfer length: 0 blocks Maximum prefetch length: 0 blocks Maximum unmap LBA count: 0 Maximum unmap block descriptor count: 0 Optimal unmap granularity: 1 Unmap granularity alignment valid: 0 Unmap granularity alignment: 0 Maximum write same length: 0x3fffc0 blocks root@sysresccd /root % grep . /sys/block/sdb/device/scsi_disk/1:0:0:0/* /sys/block/sdb/device/scsi_disk/1:0:0:0/allow_restart:1 /sys/block/sdb/device/scsi_disk/1:0:0:0/app_tag_own:0 /sys/block/sdb/device/scsi_disk/1:0:0:0/cache_type:write back grep: /sys/block/sdb/device/scsi_disk/1:0:0:0/device: Is a directory /sys/block/sdb/device/scsi_disk/1:0:0:0/FUA:0 /sys/block/sdb/device/scsi_disk/1:0:0:0/manage_start_stop:1 /sys/block/sdb/device/scsi_disk/1:0:0:0/max_medium_access_timeouts:2 /sys/block/sdb/device/scsi_disk/1:0:0:0/max_write_same_blocks:0 grep: /sys/block/sdb/device/scsi_disk/1:0:0:0/power: Is a directory /sys/block/sdb/device/scsi_disk/1:0:0:0/protection_mode:none /sys/block/sdb/device/scsi_disk/1:0:0:0/protection_type:0 /sys/block/sdb/device/scsi_disk/1:0:0:0/provisioning_mode:writesame_16 grep: /sys/block/sdb/device/scsi_disk/1:0:0:0/subsystem: Is a directory /sys/block/sdb/device/scsi_disk/1:0:0:0/thin_provisioning:1 So we can see it is really a SATA device that announces discard correctly and supports discard through WRITE_SAME(16). It is the act of passing it through Hyper-V that turned it into a SCSI device that supports UNMAP (but not WRITE_SAME(16)), doesn't announce its SCSI conformance number and doesn't correctly announce which features it supports. Surely in this case it's reasonable to quirk our way around the problem? -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Enable discard on Hyper-V
On Thu, Jul 24, 2014 at 08:47:39AM +0100, Sitsofe Wheeler wrote: > On Wed, Jul 23, 2014 at 09:13:41PM +0100, Sitsofe Wheeler wrote: > > On Wed, Jul 23, 2014 at 07:15:58AM -0700, Christoph Hellwig wrote: > > > On Wed, Jul 23, 2014 at 03:10:28PM +0100, Sitsofe Wheeler wrote: > > > > I'm not sure this alone will work - won't sdev_bflags/bflags have > > > > already been built at this point? > > > > > > They've been built up, but we can still or new values into it. It looks > > > fine to me from review, but if you can test it on an actualy hypverv > > > setup that would be valueable feedback. > > > > The previous patches didn't work for me with a Windows 2012 R2 host with a > > 3.16.0-rc6.x86_64-00076-g2f7d2ec-dirty guest. After applying > > > > > term project, this late in the 3.17 cycle I'd just like to merge > > > something that gets discards on hyperv to work. > > OK how about the following patches: > > Sitsofe Wheeler (3): > [SCSI] Add quirk for forcing logical block provisioning tests > [SCSI] storvsc: Add Hyper-V logical block provisioning quirk > [SCSI] Make LBP quirk skip lbpme checks With the updated "Make LBP quirk skip lbpme checks" the above patches enable discard on all Hyper-V disks (both VHDXs and passthrough SSDs) on Windows 2012 R2 running a Linux 3.16.0-rc6.x86_64-00076-g2f7d2ec-dirty guest. Adding back the debugging and looking at just the discard messages shows this: sd 0:0:0:0: [sda] Discard mode: 2 sd 0:0:0:0: [sda] Entering discard switch via LBP VPD sd 0:0:0:0: [sda] Discard mode: 1 sd 0:0:0:0: [sda] Discard mode: 2 sd 0:0:0:0: [sda] Entering discard switch via LBP VPD sd 0:0:0:0: [sda] Discard mode: 1 sd 0:0:0:0: [sda] Discard mode: 2 sd 0:0:0:0: [sda] Entering discard switch via LBP VPD sd 0:0:0:0: [sda] Discard mode: 1 sd 1:0:0:3: [sdd] Discard mode: 2 sd 1:0:0:1: [sdc] Entering discard switch with NO LBP VPD sd 1:0:0:1: [sdc] Discard mode: 1 sd 1:0:0:3: [sdd] Entering discard switch via LBP VPD sd 1:0:0:3: [sdd] Discard mode: 1 sd 1:0:0:0: [sdb] Discard mode: 2 sd 1:0:0:3: [sdd] Discard mode: 2 sd 1:0:0:1: [sdc] Entering discard switch with NO LBP VPD sd 1:0:0:1: [sdc] Discard mode: 1 sd 1:0:0:3: [sdd] Entering discard switch via LBP VPD sd 1:0:0:3: [sdd] Discard mode: 1 sd 1:0:0:1: [sdc] Entering discard switch with NO LBP VPD sd 1:0:0:1: [sdc] Discard mode: 1 sd 1:0:0:0: [sdb] Entering discard switch via LBP VPD sd 1:0:0:0: [sdb] Discard mode: 1 sd 1:0:0:3: [sdd] Discard mode: 2 sd 1:0:0:0: [sdb] Discard mode: 2 sd 1:0:0:0: [sdb] Entering discard switch via LBP VPD sd 1:0:0:0: [sdb] Discard mode: 1 sd 1:0:0:0: [sdb] Discard mode: 2 sd 1:0:0:0: [sdb] Entering discard switch via LBP VPD sd 1:0:0:0: [sdb] Discard mode: 1 sd 1:0:0:3: [sdd] Entering discard switch via LBP VPD sd 1:0:0:3: [sdd] Discard mode: 1 All devices eventually end up using discard mode 1 (SD_LBP_UNMAP) but it's a bit strange the VHDX devices (which set lbpme) flip back and forth between discard mode 1 and discard mode 2 (SD_LBP_WS16)... -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests
v1 -> v2: Fix incorrectly named variable. Some block devices (such as Hyper-V passthrough SSDs) support logical block provisioning (e.g. via UNMAP) but don't set lbpme thus disabling discard. If the try_lbp quirk is in use skip lbpme checks that lead up to the logical block provisioning tests. Signed-off-by: Sitsofe Wheeler --- drivers/scsi/sd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 8249e51..8bf34bc 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -2559,7 +2559,7 @@ static void sd_read_block_limits(struct scsi_disk *sdkp) sdkp->max_ws_blocks = (u32)get_unaligned_be64(&buffer[36]); - if (!sdkp->lbpme) + if (!sdkp->lbpme && !sdkp->device->try_lbp) goto out; lba_count = get_unaligned_be32(&buffer[20]); @@ -2633,7 +2633,7 @@ static void sd_read_block_provisioning(struct scsi_disk *sdkp) unsigned char *buffer; const int vpd_len = 8; - if (sdkp->lbpme == 0) + if (sdkp->lbpme == 0 && sdkp->device->try_lbp == 0) return; buffer = kmalloc(vpd_len, GFP_KERNEL); -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] [SCSI] Make LBP quirk skip lbpme checks tests
Some block devices (such as Hyper-V passthrough SSDs) support logical block provisioning (e.g. via UNMAP) but don't set lbpme thus disabling discard. If the try_lbp quirk is in use skip lbpme checks that lead up to the logical block provisioning tests. Signed-off-by: Sitsofe Wheeler --- drivers/scsi/sd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 8249e51..8bf34bc 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -2559,7 +2559,7 @@ static void sd_read_block_limits(struct scsi_disk *sdkp) sdkp->max_ws_blocks = (u32)get_unaligned_be64(&buffer[36]); - if (!sdkp->lbpme) + if (!sdkp->lbpme && !sdkp->device->try_lbp) goto out; lba_count = get_unaligned_be32(&buffer[20]); @@ -2633,7 +2633,7 @@ static void sd_read_block_provisioning(struct scsi_disk *sdkp) unsigned char *buffer; const int vpd_len = 8; - if (sdkp->lbpme == 0) + if (sdkp->lbpme == 0 && sdkp->device->test_lbp == 0) return; buffer = kmalloc(vpd_len, GFP_KERNEL); -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [SCSI] storvsc: Add Hyper-V logical block provisioning tests
Microsoft Hyper-V targets currently only claim SPC-2 compliance / no compliance indicated even though they implement post SPC-2 features which means those features are not tested for. Add a blacklist flag to Hyper-V devices that forces said testing. See https://lkml.org/lkml/2014/7/21/627 for the previous version of this patch and https://lkml.org/lkml/2014/7/23/615 for example devices. Original-patch-by: K. Y. Srinivasan Signed-off-by: Sitsofe Wheeler --- drivers/scsi/storvsc_drv.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index 5ad2810..88b7173 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -326,8 +326,6 @@ MODULE_PARM_DESC(storvsc_ringbuffer_size, "Ring buffer size (bytes)"); */ static int storvsc_timeout = 180; -static int msft_blist_flags = BLIST_TRY_VPD_PAGES; - #define STORVSC_MAX_IO_REQUESTS200 static void storvsc_on_channel_callback(void *context); @@ -1444,12 +1442,10 @@ static int storvsc_device_configure(struct scsi_device *sdevice) sdevice->no_write_same = 1; /* -* Add blist flags to permit the reading of the VPD pages even when -* the target may claim SPC-2 compliance. MSFT targets currently -* claim SPC-2 compliance while they implement post SPC-2 features. -* With this patch we can correctly handle WRITE_SAME_16 issues. +* Forcefully enable logical block provisioning testing. */ - sdevice->sdev_bflags |= msft_blist_flags; + sdevice->sdev_bflags |= BLIST_TRY_LBP; + sdevice->try_lbp = 1; return 0; } -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] [SCSI] Add quirk for forcing logical block provisioning tests
Despite supporting modern SCSI features (such an UNMAP) some storage
devices continue to claim conformance to an older version of the SPC
spec for compatibility with legacy operating systems.
Linux by default will not attempt to read VPD pages on devices that
claim SPC-2 or older.
Introduce a blacklist flag that allows the forcing of the paths leading
to logical block provisioning tests.
See https://lkml.org/lkml/2014/7/13/59 for the previous version.
Reported-by: K. Y. Srinivasan
Original-patch-by: Martin K. Petersen
Signed-off-by: Sitsofe Wheeler
---
drivers/scsi/scsi_scan.c| 4 +++-
drivers/scsi/sd.c | 8
drivers/scsi/storvsc_drv.c | 10 ++
include/scsi/scsi_device.h | 1 +
include/scsi/scsi_devinfo.h | 2 ++
5 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index e02b3aa..02ca1c2 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -950,7 +950,9 @@ static int scsi_add_lun(struct scsi_device *sdev, unsigned
char *inq_result,
sdev->eh_timeout = SCSI_DEFAULT_EH_TIMEOUT;
- if (*bflags & BLIST_SKIP_VPD_PAGES)
+ if (*bflags & BLIST_TRY_LBP)
+ sdev->try_lbp = 1;
+ else if (*bflags & BLIST_SKIP_VPD_PAGES)
sdev->skip_vpd_pages = 1;
transport_configure_device(&sdev->sdev_gendev);
diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 6825eda..8249e51 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -2109,6 +2109,8 @@ static int sd_try_rc16_first(struct scsi_device *sdp)
return 1;
if (scsi_device_protection(sdp))
return 1;
+ if (sdp->try_lbp)
+ return 1;
return 0;
}
@@ -2682,6 +2684,12 @@ static void sd_read_write_same(struct scsi_disk *sdkp,
unsigned char *buffer)
static int sd_try_extended_inquiry(struct scsi_device *sdp)
{
/*
+* Attempt VPD inquiry if the device blacklist explicitly calls
+* for it.
+*/
+ if (sdp->try_lbp)
+ return 1;
+ /*
* Although VPD inquiries can go to SCSI-2 type devices,
* some USB ones crash on receiving them, and the pages
* we currently ask for are for SPC-3 and beyond
diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c
index 9969fa1..5ad2810 100644
--- a/drivers/scsi/storvsc_drv.c
+++ b/drivers/scsi/storvsc_drv.c
@@ -326,6 +326,8 @@ MODULE_PARM_DESC(storvsc_ringbuffer_size, "Ring buffer size
(bytes)");
*/
static int storvsc_timeout = 180;
+static int msft_blist_flags = BLIST_TRY_VPD_PAGES;
+
#define STORVSC_MAX_IO_REQUESTS200
static void storvsc_on_channel_callback(void *context);
@@ -1441,6 +1443,14 @@ static int storvsc_device_configure(struct scsi_device
*sdevice)
sdevice->no_write_same = 1;
+ /*
+* Add blist flags to permit the reading of the VPD pages even when
+* the target may claim SPC-2 compliance. MSFT targets currently
+* claim SPC-2 compliance while they implement post SPC-2 features.
+* With this patch we can correctly handle WRITE_SAME_16 issues.
+*/
+ sdevice->sdev_bflags |= msft_blist_flags;
+
return 0;
}
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 27ab310..0a5c6fa 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -155,6 +155,7 @@ struct scsi_device {
unsigned skip_ms_page_8:1; /* do not use MODE SENSE page 0x08 */
unsigned skip_ms_page_3f:1; /* do not use MODE SENSE page 0x3f */
unsigned skip_vpd_pages:1; /* do not read VPD pages */
+ unsigned try_lbp:1; /* Try LBP tests */
unsigned use_192_bytes_for_3f:1; /* ask for 192 bytes from page 0x3f */
unsigned no_start_on_add:1; /* do not issue start on add */
unsigned allow_restart:1; /* issue START_UNIT in error handler */
diff --git a/include/scsi/scsi_devinfo.h b/include/scsi/scsi_devinfo.h
index 447d2d7..9d15d78 100644
--- a/include/scsi/scsi_devinfo.h
+++ b/include/scsi/scsi_devinfo.h
@@ -32,4 +32,6 @@
#define BLIST_ATTACH_PQ3 0x100 /* Scan: Attach to PQ3 devices */
#define BLIST_NO_DIF 0x200 /* Disable T10 PI (DIF) */
#define BLIST_SKIP_VPD_PAGES 0x400 /* Ignore SBC-3 VPD pages */
+#define BLIST_TRY_LBP 0x1000 /* Check Logical Block Provisioning
+ even on < SPC-3 devices */
#endif
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Enable discard on Hyper-V
On Wed, Jul 23, 2014 at 09:13:41PM +0100, Sitsofe Wheeler wrote: > On Wed, Jul 23, 2014 at 07:15:58AM -0700, Christoph Hellwig wrote: > > On Wed, Jul 23, 2014 at 03:10:28PM +0100, Sitsofe Wheeler wrote: > > > I'm not sure this alone will work - won't sdev_bflags/bflags have > > > already been built at this point? > > > > They've been built up, but we can still or new values into it. It looks > > fine to me from review, but if you can test it on an actualy hypverv > > setup that would be valueable feedback. > > The previous patches didn't work for me with a Windows 2012 R2 host with a > 3.16.0-rc6.x86_64-00076-g2f7d2ec-dirty guest. After applying > > > term project, this late in the 3.17 cycle I'd just like to merge > > something that gets discards on hyperv to work. OK how about the following patches: Sitsofe Wheeler (3): [SCSI] Add quirk for forcing logical block provisioning tests [SCSI] storvsc: Add Hyper-V logical block provisioning quirk [SCSI] Make LBP quirk skip lbpme checks drivers/scsi/scsi_scan.c| 4 +++- drivers/scsi/sd.c | 12 ++-- drivers/scsi/storvsc_drv.c | 6 ++ include/scsi/scsi_device.h | 1 + include/scsi/scsi_devinfo.h | 2 ++ 5 files changed, 22 insertions(+), 3 deletions(-) -- 1.9.3 -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Drivers: scsi: storvsc: Add blist flags
On Wed, Jul 23, 2014 at 07:15:58AM -0700, Christoph Hellwig wrote: > On Wed, Jul 23, 2014 at 03:10:28PM +0100, Sitsofe Wheeler wrote: > > I'm not sure this alone will work - won't sdev_bflags/bflags have > > already been built at this point? > > They've been built up, but we can still or new values into it. It looks > fine to me from review, but if you can test it on an actualy hypverv > setup that would be valueable feedback. The previous patches didn't work for me with a Windows 2012 R2 host with a 3.16.0-rc6.x86_64-00076-g2f7d2ec-dirty guest. After applying https://patchwork.kernel.org/patch/4541201 (which needed a small fixup) and https://patchwork.kernel.org/patch/4598601 and the attached debugging output patch here's the result I got: hv_vmbus: registering driver hv_storvsc scsi0 : storvsc_host_t scsi 0:0:0:0: scsi_get_device_flags_keyed: key: 3 scsi 0:0:0:0: scsi_get_device_flags_keyed: Post SCSI_DEVINFO_GLOBAL scsi 0:0:0:0: scsi_get_device_flags_keyed: No sdev_bflags scsi 0:0:0:0: sdev->scsi_level: 5 scsi 0:0:0:0: Direct-Access Msft Virtual Disk 1.0 PQ: 0 ANSI: 4 scsi 0:0:0:0: scsi_add_lun: Have BLIST_TRY_VPD_PAGES? No scsi 0:0:0:0: storvsc_device_configure: Added BLIST_TRY_VPD_PAGES scsi1 : storvsc_host_t sd 0:0:0:0: Attached scsi generic sg0 type 0 scsi 1:0:0:0: scsi_get_device_flags_keyed: key: 3 scsi 1:0:0:0: scsi_get_device_flags_keyed: Post SCSI_DEVINFO_GLOBAL scsi 1:0:0:0: scsi_get_device_flags_keyed: No sdev_bflags scsi 1:0:0:0: sdev->scsi_level: 5 scsi 1:0:0:0: Direct-Access Msft Virtual Disk 1.0 PQ: 0 ANSI: 4 scsi 1:0:0:0: scsi_add_lun: Have BLIST_TRY_VPD_PAGES? No scsi 1:0:0:0: storvsc_device_configure: Added BLIST_TRY_VPD_PAGES scsi 1:0:0:1: scsi_get_device_flags_keyed: key: 5 scsi 1:0:0:1: scsi_get_device_flags_keyed: Post SCSI_DEVINFO_GLOBAL scsi 1:0:0:1: scsi_get_device_flags_keyed: No sdev_bflags scsi 1:0:0:1: scsi_get_device_flags_keyed: key: 5 scsi 1:0:0:1: scsi_get_device_flags_keyed: Post SCSI_DEVINFO_GLOBAL scsi 1:0:0:1: scsi_get_device_flags_keyed: No sdev_bflags scsi 1:0:0:1: sdev->scsi_level: 0 scsi 1:0:0:1: Direct-Access ADATASSD S510 120GB 5.2. PQ: 0 ANSI: 0 scsi 1:0:0:1: scsi_add_lun: Have BLIST_TRY_VPD_PAGES? No scsi 1:0:0:1: storvsc_device_configure: Added BLIST_TRY_VPD_PAGES scsi 1:0:0:3: scsi_get_device_flags_keyed: key: 0 scsi 1:0:0:3: scsi_get_device_flags_keyed: Post SCSI_DEVINFO_GLOBAL scsi 1:0:0:3: scsi_get_device_flags_keyed: No sdev_bflags scsi 1:0:0:3: sdev->scsi_level: 5 scsi 1:0:0:3: Direct-Access Msft Virtual Disk 1.0 PQ: 0 ANSI: 4 scsi 1:0:0:3: scsi_add_lun: Have BLIST_TRY_VPD_PAGES? No scsi 1:0:0:3: storvsc_device_configure: Added BLIST_TRY_VPD_PAGES sd 1:0:0:0: sd_try_rc16_first: sdp->scsi_level: 5 sd 1:0:0:0: [sdb] 2097152 512-byte logical blocks: (1.07 GB/1.00 GiB) sd 1:0:0:0: [sdb] sd_revalidate_disk: Extended inquiry check... sd 1:0:0:0: [sdb] sd_revalidate_disk: Skipped extended inquiries sd 1:0:0:0: [sdb] Write Protect is off sd 1:0:0:0: [sdb] Mode Sense: 0f 00 00 00 sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: sd_try_rc16_first: sdp->scsi_level: 5 ata_piix :00:07.1: version 2.13 sd 1:0:0:0: sd_try_rc16_first: sdp->scsi_level: 5 sd 1:0:0:0: [sdb] sd_revalidate_disk: Extended inquiry check... sd 1:0:0:0: [sdb] sd_revalidate_disk: Skipped extended inquiries sdb: unknown partition table ata_piix :00:07.1: Hyper-V Virtual Machine detected, ATA device ignore set sd 1:0:0:0: sd_try_rc16_first: sdp->scsi_level: 5 sd 1:0:0:0: [sdb] sd_revalidate_disk: Extended inquiry check... sd 1:0:0:0: [sdb] sd_revalidate_disk: Skipped extended inquiries sd 1:0:0:0: [sdb] Attached SCSI disk sd 1:0:0:0: Attached scsi generic sg1 type 0 sd 0:0:0:0: [sda] 8388608 512-byte logical blocks: (4.29 GB/4.00 GiB) scsi2 : ata_piix scsi3 : ata_piix ata1: PATA max UDMA/33 cmd 0x1f0 ctl 0x3f6 bmdma 0xffa0 irq 14 ata2: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0xffa8 irq 15 sd 1:0:0:1: Attached scsi generic sg2 type 0 libphy: Fixed MDIO Bus: probed hv_vmbus: registering driver hv_netvsc sd 1:0:0:3: Attached scsi generic sg3 type 0 hv_netvsc: hv_netvsc channel opened successfully sd 0:0:0:0: [sda] sd_revalidate_disk: Extended inquiry check... sd 0:0:0:0: [sda] sd_revalidate_disk: Skipped extended inquiries sd 1:0:0:1: sd_try_rc16_first: sdp->scsi_level: 0 sd 1:0:0:3: sd_try_rc16_first: sdp->scsi_level: 5 sd 1:0:0:1: [sdc] 234441648 512-byte logical blocks: (120 GB/111 GiB) sd 1:0:0:1: [sdc] sd_revalidate_disk: Extended inquiry check... sd 1:0:0:1: [sdc] sd_revalidate_disk: Skipped extended inquiries sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 0f 00 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: sd_try_rc16_first: sdp->scsi_level: 5 sd 0:0:0:0: [sda] sd_revalidate_disk: Extended inquiry
Re: [PATCH 1/1] Drivers: scsi: storvsc: Add blist flags
On Wed, Jul 23, 2014 at 07:10:14AM -0700, Christoph Hellwig wrote: > On Wed, Jul 23, 2014 at 01:54:43PM +0100, Sitsofe Wheeler wrote: > > That's good to know (I was worried the device would not be detected as > > supporting discard because it doesn't report lbpme and doesn't declare a > > conformance version (see below)). > > Ok, that makes things worse - you might be able to force it through > sysfs, though. I've got a hack that seems to be working for me - see below. > > Is there a tree with all these updates > > in or do they need to be pieced together from this email thread? > > I'm picking this up for my scsi-queue tree. Still need a review > for the patch we're replying to before that one can go in, though. OK. > > Additionally is it worth quirking sd_try_rc16_first on when > > BLIST_TRY_VPD_PAGES is present? > > Sounds reasonable to me. OK did you want me to post a set of changes to your patch? I've basically changed the patches from bypassing the SCSI level check (to allow scanning of VPD pages) to also try READ_CAPACITY(16) first and bypass lbpme checks. Now it's more of a case of BLIST_TRY_LBP... -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Drivers: scsi: storvsc: Add blist flags
On Mon, Jul 21, 2014 at 04:06:01PM -0700, K. Y. Srinivasan wrote: > Add blist flags to permit the reading of the VPD pages even when > the target may claim SPC-2 compliance. MSFT targets currently > claim SPC-2 compliance while they implement post SPC-2 features. > With this patch we can correctly handle WRITE_SAME_16 issues. > > static void storvsc_on_channel_callback(void *context); > @@ -1449,6 +1451,14 @@ static int storvsc_device_configure(struct scsi_device > *sdevice) > > sdevice->no_write_same = 1; > > + /* > + * Add blist flags to permit the reading of the VPD pages even when > + * the target may claim SPC-2 compliance. MSFT targets currently > + * claim SPC-2 compliance while they implement post SPC-2 features. > + * With this patch we can correctly handle WRITE_SAME_16 issues. > + */ > + sdevice->sdev_bflags |= msft_blist_flags; > + I'm not sure this alone will work - won't sdev_bflags/bflags have already been built at this point? If the setting of this has to stay in this function why don't you (also) set sdevice->try_vpd_pages in a similar way to no_write_same? -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Drivers: scsi: storvsc: Add blist flags
On Wed, Jul 23, 2014 at 04:51:28AM -0700, Christoph Hellwig wrote: > On Wed, Jul 23, 2014 at 11:04:48AM +0100, Sitsofe Wheeler wrote: > > OK I've just seen this as I was about to post a similar patch to get > > discard going on Hyper-V. Will your patches handle Hyper-V pass through > > devices > > that support discard? The SSD I have here reports the following in the Linux > > VM: > > I didn't know hyperv also supports pass through, but it should work fine. > The only thing I'm worried about is real SCSI-2 devices or crappy USB > devices that don't support EVPD pages and might cause problems. But > let's ignore that problem for now.. That's good to know (I was worried the device would not be detected as supporting discard because it doesn't report lbpme and doesn't declare a conformance version (see below)). Is there a tree with all these updates in or do they need to be pieced together from this email thread? Additionally is it worth quirking sd_try_rc16_first on when BLIST_TRY_VPD_PAGES is present? # sg_inq /dev/sdc standard INQUIRY: PQual=0 Device_type=0 RMB=0 version=0x00 [no conformance claimed] [AERC=0] [TrmTsk=0] NormACA=0 HiSUP=0 Resp_data_format=2 SCCS=0 ACC=0 TPGS=0 3PC=0 Protect=0 [BQue=0] EncServ=0 MultiP=0 [MChngr=0] [ACKREQQ=0] Addr16=0 [RelAdr=0] WBus16=0 Sync=0 Linked=0 [TranDis=0] CmdQue=1 [SPI: Clocking=0x0 QAS=0 IUS=0] length=60 (0x3c) Peripheral device type: disk Vendor identification: ADATA Product identification: SSD S510 120GB Product revision level: 5.2. Unit serial number: 0320511550032076 -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Drivers: scsi: storvsc: Add blist flags
On Mon, Jul 21, 2014 at 04:06:01PM -0700, K. Y. Srinivasan wrote: > Add blist flags to permit the reading of the VPD pages even when > the target may claim SPC-2 compliance. MSFT targets currently > claim SPC-2 compliance while they implement post SPC-2 features. > With this patch we can correctly handle WRITE_SAME_16 issues. OK I've just seen this as I was about to post a similar patch to get discard going on Hyper-V. Will your patches handle Hyper-V pass through devices that support discard? The SSD I have here reports the following in the Linux VM: # sg_vpd -p lbpv /dev/sdc Logical block provisioning VPD page (SBC): Unmap command supported (LBPU): 1 Write same (16) with unmap bit supported (LBWS): 0 Write same (10) with unmap bit supported (LBWS10): 0 Logical block provisioning read zeros (LBPRZ): 0 Anchored LBAs supported (ANC_SUP): 1 Threshold exponent: 0 Descriptor present (DP): 0 Provisioning type: 0 # sg_readcap -l /dev/sdc Read Capacity results: Protection: prot_en=0, p_type=0, p_i_exponent=0 Logical block provisioning: lbpme=0, lbprz=0 Last logical block address=234441647 (0xdf94baf), Number of logical blocks=234441648 Logical block length=512 bytes Logical blocks per physical block exponent=0 Lowest aligned logical block address=0 Hence: Device size: 120034123776 bytes, 114473.5 MiB, 120.03 GB -- Sitsofe | http://sucs.org/~sits/ -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
