[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 0 0B 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
