Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Thu, Mar 15, 2018 at 04:46:30PM +0100, Kashyap Chamarthy wrote: > (Sorry, accidentally dropped the lists. Adding it back & re-posting my > off-list response.) (Now add the missing linux-usb@vger.kernel.org list for real. Not trimming the full e-mail intentionally as I missed to Cc 'linux-usb'.) > On Thu, Mar 15, 2018 at 04:05:53PM +0100, Kashyap Chamarthy wrote: > > On Thu, Mar 15, 2018 at 03:33:46PM +0100, Douglas Gilbert wrote: > > > On 2018-03-15 02:44 PM, Douglas Gilbert wrote: > > > > On 2018-03-15 01:45 PM, Martin K. Petersen wrote: > > > > > > > > > > Kashyap, > > > > > > > > > > > /me naively wonders if it has anything to do with accessing it via > > > > > > Linux. > > > > > > > > > > I'm guessing that the drive doesn't actually support SCSI UNMAP. I > > > > > have > > > > > a T3 that reports all the right things in the bl/lbpv VPD pages but > > > > > also > > > > > has lbpme set to 0. > > > > > > > > > > Interestingly enough, my T3 does appear to be a regular SATA drive > > > > > behind a USB bridge. Have you tried to issue a DSM TRIM command via > > > > > ATA > > > > > passthrough? > > > > > > > > hdparm can do that. Look for "EXCEPTIONALLY DANGEROUS. DO NOT USE THIS > > > > OPTION!!" in its manpage :-) > > > > Hehe, near as I see, that's dangerous only if you have data on the disk. > > > > This is an empty SSD that I haven't put any data in it, I should remind. > > :-) In that case, I'll assume it is "safe" to tinker with the above. > > > > > IOWs, using Mark Lord's example: > > >hdparm --trim-sector-ranges 1000:4 /dev/sdz > > > > > > That will attempt to trim lba 1000, 1001, 1002 and 1003 on /dev/sdz > > > > Thanks; I should first educate myself more on this before I tinker with > > the above. One Ubuntu wiki page claims: "To wipe out contents of an SSD, > > SATA secure erase is the way to go", Never mind about "secure erase", even trying to set password via `hdparm' for this T5 SSD (still connected via 'Thunderbolt'): $> hdparm --user-master u --security-set-pass $SECRET /dev/sdc Fails with the unactionable & useless error: "SECURITY_SET_PASS: Input/output error" > > and '--trim-sector-ranges' is only > > "experimental and for benchmarking purpose". > > > > Just to recap: My goal is to clean (insofar as possible) the SSD of all > > and any / all pre-loaded programs & re-claim space. > > > > --- > > > > Related: The ATA Secure Erase wiki page claims[*] if you do it (Secure > > Erase) via USB interface, you might brick the SSD. I'm using the > > 'Thunderbolt' interface, and the said wiki page doesn't say anything > > useful about it. > > > > > > [*] https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase -- /kashyap -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Thu, Mar 15, 2018 at 08:45:05AM -0400, Martin K. Petersen wrote:
>
> Kashyap,
>
> > /me naively wonders if it has anything to do with accessing it via
> > Linux.
>
> I'm guessing that the drive doesn't actually support SCSI UNMAP. I have
> a T3 that reports all the right things in the bl/lbpv VPD pages but also
> has lbpme set to 0.
>
> Interestingly enough, my T3 does appear to be a regular SATA drive
> behind a USB bridge.
I see. So I ran `hdparm` on my SSD (still attached via the
'Thunderbolt' port), and it does show TRIM support:
$> hdparm -I /dev/sdc | grep TRIM
*Data Set Management TRIM supported (limit 8 blocks)
(Full output attached to this e-mail as a text file.)
> Have you tried to issue a DSM TRIM command via ATA
> passthrough?
I'm afraid I don't know how to do that (my SCSI / (S)ATA knowledge is
less than zero). If there's a page where I can educate myself about how
to send the TRIM command via ATA passthrough I'd appreciate it. (Aside:
>From my looking up, I don't see any ATA equivalent of SCSI's
'sg3_utils'; wonder if there is any.)
Thanks for the response.
--
/kashyap
$> hdparm -I /dev/sdc
/dev/sdc:
ATA device, with non-removable media
Model Number: Samsung Portable SSD T5
Serial Number: S3UNNV0K102165T
Firmware Revision: MVT41P1Q
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions,
SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Used: unknown (minor revision code 0x0039)
Supported: 9 8 7 6 5
Likely used: 9
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors:16514064
LBAuser addressable sectors: 268435455
LBA48 user addressable sectors: 976773168
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 1024*1024: 476940 MBytes
device size with M = 1000*1000: 500107 MBytes (500 GB)
cache/buffer size = unknown
Form Factor: unknown (0x0006]
Nominal Media Rotation Rate: Solid State Device
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 1 Current = 1
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
*SMART feature set
*Power Management feature set
*Write cache
*Look-ahead
*WRITE_BUFFER command
*READ_BUFFER command
*NOP cmd
*DOWNLOAD_MICROCODE
SET_MAX security extension
*48-bit Address feature set
*Mandatory FLUSH_CACHE
*FLUSH_CACHE_EXT
*SMART error logging
*SMART self-test
*General Purpose Logging feature set
*WRITE_{DMA|MULTIPLE}_FUA_EXT
*64-bit World wide name
Write-Read-Verify feature set
*WRITE_UNCORRECTABLE_EXT command
*{READ,WRITE}_DMA_EXT_GPL commands
*Segmented DOWNLOAD_MICROCODE
*Gen1 signaling speed (1.5Gb/s)
*Gen2 signaling speed (3.0Gb/s)
*Gen3 signaling speed (6.0Gb/s)
*Native Command Queueing (NCQ)
*Phy event counters
*READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
DMA Setup Auto-Activate optimization
*Device-initiated interface power management
*Software settings preservation
*reserved 69[4]
*DOWNLOAD MICROCODE DMA command
*SET MAX SETPASSWORD/UNLOCK DMA commands
*WRITE BUFFER DMA command
*READ BUFFER DMA command
*Data Set Management TRIM supported (limit 8 blocks)
Logical Unit WWN Device Identifier: 5002538d
NAA : 5
IEEE OUI: 002538
Unique ID : d
Checksum: correct
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On 2018-03-15 01:45 PM, Martin K. Petersen wrote: Kashyap, /me naively wonders if it has anything to do with accessing it via Linux. I'm guessing that the drive doesn't actually support SCSI UNMAP. I have a T3 that reports all the right things in the bl/lbpv VPD pages but also has lbpme set to 0. Interestingly enough, my T3 does appear to be a regular SATA drive behind a USB bridge. Have you tried to issue a DSM TRIM command via ATA passthrough? hdparm can do that. Look for "EXCEPTIONALLY DANGEROUS. DO NOT USE THIS OPTION!!" in its manpage :-) Doug Gilbert -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
Kashyap, > /me naively wonders if it has anything to do with accessing it via > Linux. I'm guessing that the drive doesn't actually support SCSI UNMAP. I have a T3 that reports all the right things in the bl/lbpv VPD pages but also has lbpme set to 0. Interestingly enough, my T3 does appear to be a regular SATA drive behind a USB bridge. Have you tried to issue a DSM TRIM command via ATA passthrough? -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Thu, Mar 15, 2018 at 12:19:11PM +0100, Douglas Gilbert wrote: > On 2018-03-15 10:47 AM, Kashyap Chamarthy wrote: > > On Wed, Mar 14, 2018 at 11:43:55PM -0400, Martin K. Petersen wrote: > > > > > > Kashyap, > > > > Hi Martin, > > > > > > Sorry, I didn't give you complete information — with the previous > > > > `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB > > > > "A Cable". > > > > > > > > Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop > > > > (Lenovo T470s), it _does_ show "UAS". Refer the arrow below: > > > > > > Do you get different sg_readcap -l output when accessing it in UAS mode? > > > I.e. is lbpme=1? > > > > Afraid, no :-( I was excited for a brief moment, but it's the same as > > earlier. The result with the SSD via 'Thunderbolt': > > > > $> sudo 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=976773167 (0x3a38602f), Number of > > logical blocks=976773168 > > Logical block length=512 bytes > > Logical blocks per physical block exponent=0 > > Lowest aligned logical block address=0 > > Hence: > > Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB > > > > > > /me naively wonders if it has anything to do with accessing it via > > Linux. > > You can also run 'sg_readcap -l' on a Windows machine to test your theory. > Do 'sg_scan.exe' first to see where (and if) the 'physical disk' is, then > you would do something like: > sg_readcap -l pd2 > > There is no IOS port of sg3_utils. > > I am not aware of any SCSI command *** (and haven't seen any ATA or NVMe > commands) that tell a storage device something like: "BTW I'm a Linux > machine running Ubuntu 17.10 on hardware". > > It is possible that a storage device might recognize an OS by the pattern > of commands it sends, especially in the device discovery mode. > > So basically your suggestion is a long shot. There might be a "secret" > setting in a vendor specific command that another OS is aware of. > For example, according to the 'net this command: >sg_raw /dev/sr0 EA 00 00 00 00 00 01 > allows owners of Apple USB Superdrives to use them on other OSes. I see, thanks for the explanation and the specific useful commands. I'll try to get hold of a friend's Windows computer, as I don't have one with me. But your "long shot" comment adjusted my expectations to not hold my breath. > *** there are transport_ids used by PERSISTENT RESERVATION commands to > differentiate one machine from another. But they convey about as > much information as a random number does. Also that applies to a > multi-initiator, single target model which isn't the case when we > are talking about USB/Thunderbolt attachment. > -- /kashyap -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On 2018-03-15 10:47 AM, Kashyap Chamarthy wrote: On Wed, Mar 14, 2018 at 11:43:55PM -0400, Martin K. Petersen wrote: Kashyap, Hi Martin, Sorry, I didn't give you complete information — with the previous `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB "A Cable". Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop (Lenovo T470s), it _does_ show "UAS". Refer the arrow below: Do you get different sg_readcap -l output when accessing it in UAS mode? I.e. is lbpme=1? Afraid, no :-( I was excited for a brief moment, but it's the same as earlier. The result with the SSD via 'Thunderbolt': $> sudo 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=976773167 (0x3a38602f), Number of logical blocks=976773168 Logical block length=512 bytes Logical blocks per physical block exponent=0 Lowest aligned logical block address=0 Hence: Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB /me naively wonders if it has anything to do with accessing it via Linux. You can also run 'sg_readcap -l' on a Windows machine to test your theory. Do 'sg_scan.exe' first to see where (and if) the 'physical disk' is, then you would do something like: sg_readcap -l pd2 There is no IOS port of sg3_utils. I am not aware of any SCSI command *** (and haven't seen any ATA or NVMe commands) that tell a storage device something like: "BTW I'm a Linux machine running Ubuntu 17.10 on hardware". It is possible that a storage device might recognize an OS by the pattern of commands it sends, especially in the device discovery mode. So basically your suggestion is a long shot. There might be a "secret" setting in a vendor specific command that another OS is aware of. For example, according to the 'net this command: sg_raw /dev/sr0 EA 00 00 00 00 00 01 allows owners of Apple USB Superdrives to use them on other OSes. Doug Gilbert *** there are transport_ids used by PERSISTENT RESERVATION commands to differentiate one machine from another. But they convey about as much information as a random number does. Also that applies to a multi-initiator, single target model which isn't the case when we are talking about USB/Thunderbolt attachment. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Wed, Mar 14, 2018 at 11:43:55PM -0400, Martin K. Petersen wrote: > > Kashyap, Hi Martin, > > Sorry, I didn't give you complete information — with the previous > > `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB > > "A Cable". > > > > Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop > > (Lenovo T470s), it _does_ show "UAS". Refer the arrow below: > > Do you get different sg_readcap -l output when accessing it in UAS mode? > I.e. is lbpme=1? Afraid, no :-( I was excited for a brief moment, but it's the same as earlier. The result with the SSD via 'Thunderbolt': $> sudo 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=976773167 (0x3a38602f), Number of logical blocks=976773168 Logical block length=512 bytes Logical blocks per physical block exponent=0 Lowest aligned logical block address=0 Hence: Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB /me naively wonders if it has anything to do with accessing it via Linux. -- /kashyap -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
Kashyap, > Sorry, I didn't give you complete information — with the previous > `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB > "A Cable". > > Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop > (Lenovo T470s), it _does_ show "UAS". Refer the arrow below: Do you get different sg_readcap -l output when accessing it in UAS mode? I.e. is lbpme=1? -- Martin K. Petersen Oracle Linux Engineering -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Wed, Mar 14, 2018 at 12:29:50PM +0100, Oliver Neukum wrote: > Am Mittwoch, den 14.03.2018, 11:22 +0100 schrieb Kashyap Chamarthy: > > I see. So I ran `dmesg -w`, as I attached the disk & see the following: > > UAS and no quirk for your device. It looks like it indeed just does > not support TRIM. Sorry, I didn't give you complete information — with the previous `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB "A Cable". Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop (Lenovo T470s), it _does_ show "UAS". Refer the arrow below: [...] [131839.680706] usb 4-1: new SuperSpeedPlus USB device number 2 using xhci_hcd [131839.698814] usb 4-1: New USB device found, idVendor=04e8, idProduct=61f5 [131839.698817] usb 4-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [131839.698818] usb 4-1: Product: Portable SSD T5 [131839.698819] usb 4-1: Manufacturer: Samsung [131839.698820] usb 4-1: SerialNumber: 1234567A7AD6 [131839.701232] scsi host2: uas <--- [131839.701631] scsi 2:0:0:0: Direct-Access Samsung Portable SSD T5 0 PQ: 0 ANSI: 6 [131839.703470] sd 2:0:0:0: Attached scsi generic sg1 type 0 [131839.705486] sd 2:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/466 GiB) [131839.705895] sd 2:0:0:0: [sdc] Write Protect is off [131839.705900] sd 2:0:0:0: [sdc] Mode Sense: 43 00 00 00 [131839.706146] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [131839.709656] sd 2:0:0:0: [sdc] Attached SCSI disk [131839.927167] EXT4-fs (sdc): recovery complete [131839.927175] EXT4-fs (sdc): mounted filesystem with ordered data mode. Opts: (null) [...] -- /kashyap -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
Am Mittwoch, den 14.03.2018, 11:22 +0100 schrieb Kashyap Chamarthy: > I see. So I ran `dmesg -w`, as I attached the disk & see the following: UAS and no quirk for your device. It looks like it indeed just does not support TRIM. Sorry Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Wed, Mar 14, 2018 at 10:52:36AM +0100, Oliver Neukum wrote: > Am Dienstag, den 13.03.2018, 12:50 +0100 schrieb Kashyap Chamarthy: > > Earlier, I didn't know which list to email, so I wrote to Martin K. > > Petersen (who pointed me to the lists when I asked where I can post > > publicly), and he made this observation on the above quoted text: > > > > "Linux can run USB block devices in either legacy or UAS mode. > > Chances are this device is being driven in usb-storage mode. We > > usually have quirks based on the model strings that decide whether > > to use one or the other." > > Neither driver would edit commands or result to that degree. > Whether UAS or storage are used dmesg will tell you. I see. So I ran `dmesg -w`, as I attached the disk & see the following: --- [...] [474027.606253] sd 3:0:0:0: Attached scsi generic sg1 type 0 [474027.607751] sd 3:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/466 GiB) [474027.607857] sd 3:0:0:0: [sdb] Write Protect is off [474027.607858] sd 3:0:0:0: [sdb] Mode Sense: 43 00 00 00 [474027.608019] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [474027.612347] sd 3:0:0:0: [sdb] Attached SCSI disk [474027.863216] EXT4-fs (sdb): recovery complete [474027.866955] EXT4-fs (sdb): mounted filesystem with ordered data mode. Opts: (null) [474038.146095] usb 3-1: USB disconnect, device number 4 [474038.147543] print_req_error: I/O error, dev sdb, sector 0 [474038.155354] sd 3:0:0:0: [sdb] Synchronizing SCSI cache [474038.175128] print_req_error: I/O error, dev sdb, sector 0 [474038.179130] print_req_error: I/O error, dev sdb, sector 0 [474038.183135] print_req_error: I/O error, dev sdb, sector 0 [474038.183156] print_req_error: I/O error, dev sdb, sector 0 [474038.267134] sd 3:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK [474076.230377] usb 3-1: new SuperSpeed USB device number 5 using xhci_hcd [474076.248589] usb 3-1: New USB device found, idVendor=04e8, idProduct=61f5 [474076.248593] usb 3-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [474076.248596] usb 3-1: Product: Portable SSD T5 [474076.248598] usb 3-1: Manufacturer: Samsung [474076.248600] usb 3-1: SerialNumber: 1234567A7AD6 [474076.254990] scsi host3: uas [474076.255605] scsi 3:0:0:0: Direct-Access Samsung Portable SSD T5 0 PQ: 0 ANSI: 6 [474076.263707] sd 3:0:0:0: Attached scsi generic sg1 type 0 [474076.264140] sd 3:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/466 GiB) [474076.264220] sd 3:0:0:0: [sdb] Write Protect is off [474076.264222] sd 3:0:0:0: [sdb] Mode Sense: 43 00 00 00 [474076.264546] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [474076.267595] sd 3:0:0:0: [sdb] Attached SCSI disk [474076.463067] EXT4-fs (sdb): recovery complete [474076.463070] EXT4-fs (sdb): mounted filesystem with ordered data mode. Opts: (null) --- -- /kashyap -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
Am Dienstag, den 13.03.2018, 12:50 +0100 schrieb Kashyap Chamarthy: > Earlier, I didn't know which list to email, so I wrote to Martin K. > Petersen (who pointed me to the lists when I asked where I can post > publicly), and he made this observation on the above quoted text: > > "Linux can run USB block devices in either legacy or UAS mode. > Chances are this device is being driven in usb-storage mode. We > usually have quirks based on the model strings that decide whether > to use one or the other." Neither driver would edit commands or result to that degree. Whether UAS or storage are used dmesg will tell you. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Tue, Mar 13, 2018 at 12:42:47PM +0100, Kashyap Chamarthy wrote: > [Cross-posted to 'linux-scsi' and 'linux-usb' lists; please keep me > Cced, as I'm not subscribed to either of them.) [...] > I was suggested to return this SSD. But the Interweb[%] claims Samsung > T5 *does* have 'TRIM' (i.e. SCSI 'UNMAP') support via UASP. Earlier, I didn't know which list to email, so I wrote to Martin K. Petersen (who pointed me to the lists when I asked where I can post publicly), and he made this observation on the above quoted text: "Linux can run USB block devices in either legacy or UAS mode. Chances are this device is being driven in usb-storage mode. We usually have quirks based on the model strings that decide whether to use one or the other." [...] -- /kashyap -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
[Cross-posted to 'linux-scsi' and 'linux-usb' lists; please keep me
Cced, as I'm not subscribed to either of them.)
I unboxed a brand new Samsung T5 SSD[*]. Then formatted it with EXT4
filesystem. I wanted to clean the disk of any existing software, so I
was reminded by a colleague to use `blkdiscard`. Giving it a try ... it
fails right off the bat:
$> sudo blkdiscard /dev/sdc
blkdiscard: /dev/sdc1: BLKDISCARD ioctl failed: Operation not supported
Hmm. Let's run `lsblk -D` to see if it shows discarding support (SCSI
'UNMAP' or 'TRIM' in ATA parlance) for the SSD ('sdc'). It doesn't
(from what I learn, the value of "DISC-GRAN" should be non-zero):
$> lsblk -D
NAME DISC-ALN DISC-GRAN DISC-MAX
DISC-ZERO
sdc 00B 0B
0
[...]
Next, Paolo Bonzini (KVM / QEMU maintainer) told me on IRC to run a
couple of SCSI commands[+]. The key one being the `sg_readcap`, and
here's where I learnt the bad news that the SCSI "Logical block
provisioning" ('lbpme') bit seemed to be turned off at hardware level:
$> sudo sg_readcap --16 /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=976773167 (0x3a38602f), Number of logical
blocks=976773168
Logical block length=512 bytes
Logical blocks per physical block exponent=0
Lowest aligned logical block address=0
Hence:
Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB
As another attempt, Paolo suggested to try UNMAP the following way. But
it fails with not much actionable error:
$> num=$(sg_readcap -b /dev/sdc | awk '{print $1}')
$> sg_unmap --lba=0 --num=$num /dev/sdc -v
unmap cdb: 42 00 00 00 00 00 00 00 18 00
unmap: transport: Host_status=0x01 [DID_NO_CONNECT]
Driver_status=0x00 [DRIVER_OK]
UNMAP failed (use '-v' to get more information)
* * *
Apparently there are two potential causes:
(1) Seems 'lbpme' is diasbled at the hardware-level (lbpme=0); or
(2) The firmware itself is buggy
I was suggested to return this SSD. But the Interweb[%] claims Samsung
T5 *does* have 'TRIM' (i.e. SCSI 'UNMAP') support via UASP.
My main purpose of this external hard disk is to store live VM disk
iamges. At some future point I may want to test "real" discard. I
learn, since the drive doesn't support it, the host kernel's drivers
won't be running the full SCSI discard code path. So the said SSD won't
be suitable for that.
Wonder if you have any suggestions / remarks before I return this disk?
(Assuming there's no way to enable UNMAP for this disk, and the only
recourse is to return it.)
Thanks!
[+] The outputs of `sg_vpd` & `sg_sat_identify` commands here:
https://kashyapc.fedorapeople.org/temp/sg_vpd.txt
https://kashyapc.fedorapeople.org/temp/sg_sat_identify.txt
[*] http://www.samsung.com/semiconductor/minisite/ssd/product/portable/t5/
[%] http://www.tomshardware.com/reviews/samsung-t5-portable-ssd,5163-3.html
--
/kashyap
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
