Linux/TUSB9261: TRIM support in BOT mode

MKo

Part Number: TUSB9261

Tool/software: Linux

Hi,

we are operating an mSATA device behind a TUSB9261 (v1.05) under Linux 3.14 with ext4. The usb-storage driver tells us that the WRITE SAME SCSI command is not supported by the device.

There is still the UNMAP SCSI command which could activate TRIM. However, does the TUSB firmware translate this command into the TRIM ATA command and provide support for that?

Are there any other ideas how to trigger TRIM in BOT mode?

Thanks for every hint!

over 8 years ago

0 Brian Quach over 8 years ago

TI__Expert 4325 points

UNMAP command will work for TRIM. What program is using WRITE SAME? I have only seen UNMAP used.

Regards,

Brian

0 MKo over 8 years ago in reply to Brian Quach

Intellectual 310 points

Brian Quach said:

UNMAP command will work for TRIM.

Ok thanks. In the meantime we found that sg_vpd (from sg3_utils) reports support for the UNMAP command. However, the Linux kernel does not execute the SCSI commands to query this information. Hm. We'll probably have to patch the kernel.

Brian Quach said:

What program is using WRITE SAME? I have only seen UNMAP used.

The kernel would do this if the SCSI device reports support for this command.

0 MKo over 8 years ago in reply to Brian Quach

Intellectual 310 points

We've now patched the kernel to support the UNMAP command for an mSATA behind your TUSB9261. However, the TUSB9261 firmware does not set the LBPME (Logical Block Provisioning Management Enabled) Bit in its response to the READ CAPACITY (16) command and therefore the kernel does not continue to use the UNMAP command. Is there a firmware which support this? Otherwise we'd have to hard-code this into the kernel (which is some sort of SCSI standard violation).

0 Brian Quach over 8 years ago in reply to MKo

TI__Expert 4325 points

Our Logical Block Provisioning VPD page, reports only support for UNMAP command. LBPWS and LBPWS10 bits are set to zero so the host should not use Write Same.

0 Brian Quach over 8 years ago in reply to MKo

TI__Expert 4325 points

Setting LBPME bit will be a bit more involved than just modifying that single bit. SCSI / ATA Translation - 3 rev2 spec is not clear on the implementation and I'm not sure how to determine resource vs thin provisioned.

0 MKo over 8 years ago in reply to Brian Quach

Intellectual 310 points

The SAT-3 Rev 7 Draft and SAT-4 Rev 6 Draft is quite clear:

LBPME:
If the ATA IDENTIFY DEVICE data log TRIM SUPPORTED bit is set to one and the ATA IDENTIFY DEVICE data log DRAT SUPPORTED bit is set to one, then this bit shall be set to one. Otherwise, this bit shall be set to zero.

See
standards.incits.org/.../eb-2014-00740-Public-review- register-INCITS-517-201x-Comments-due-11-24-2014.pdf
standards.incits.org/.../eb-2016-00683-Public-review-register-INCITS-491-SAT-4-Comments-due-1-31-2017.pdf

0 Brian Quach over 8 years ago in reply to MKo

TI__Expert 4325 points

Thanks for the info. I did not have this newer spec version. Can you test the attached FW?

TUSB926x_Firmware_v1.06_LBPME_fix.zip

0 Brian Quach over 8 years ago in reply to Brian Quach

TI__Expert 4325 points

Disregard the last FW provided. I found a typo in one of the VPD page bits. I corrected it and added support for RZAT. Try this one and let me know the result.

0284.TUSB926x_Firmware_vv1.06_LBPME_fix2.zip

0 MKo over 8 years ago in reply to Brian Quach

Intellectual 310 points

Thanks for providing a new FW. Unfortunately, it still returns LBPME=0 with our SSDs (checked with sg_readcap -l /dev/sg0). Anyway, in the meantime we have patched the Linux kernel where an fstrim on an ext4 now leads to the generation of USB URBs with UNMAP commands.

0 Brian Quach over 8 years ago in reply to MKo

TI__Expert 4325 points

That's strange. I am setting the bits according to the spec you provided. Do you have a UART debug log from the TUSB9261 and/or a USB trace you can share? I'd like to get it right even if you have a patch already.

0 MKo over 8 years ago in reply to Brian Quach

Intellectual 310 points

Unfortunately we cannot provide a UART log. We've tested with two SSDs but both report that LBPME is not supported. Do you see a different output?

# ./sg_readcap -l /dev/sg0
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=250069679 (0xee7c2af), Number of logical blocks=250069680
   Logical block length=512 bytes
   Logical blocks per physical block exponent=0
   Lowest aligned logical block address=0
Hence:
   Device size: 128035676160 bytes, 122104.3 MiB, 128.04 GB

0 Brian Quach over 8 years ago in reply to MKo

TI__Expert 4325 points

We tested the new FW (TUSB926x_Firmware_vv1.06_LBPME_fix2.zip) previously provided and it works as expected. LBPME bit is set because the SSD drive supports TRIM. The SSD drives you have must not be setting the TRIM support bits properly in response to IDENTIFY DEVICE command.

root@swatubuntu16-XPS-8700:~# sg_readcap -l /dev/sg1

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=250069679 (0xee7c2af), Number of logical blocks=250069680

Logical block length=512 bytes

Logical blocks per physical block exponent=0

Lowest aligned logical block address=0

Hence:

Device size: 128035676160 bytes, 122104.3 MiB, 128.04 GB

UART Output from TUSB9261:

[0000000461] ================================================
[0000000461]              IDENTIFY DEVICE INFO
[0000000461] ================================================
[0000000461]
[0000000461]   Model: TOSHIBA THNSNS128GCSP
[0000000461]   FW Rev: TA4ABBF0
[0000000461]   Serial: 925S10URT2JY
[0000000461]   TRIM Support: Yes [DRAT]
[0000000461]
[0000000461]   Spec Compliance: ATA-7
[0000000461]   Removable Media: No
[0000000461]   UDMA Modes = 0x207f
[0000000461]   PIO Modes = 0x0003
[0000000461]
[0000000461]   LBA48: Yes
[0000000461]   Max LBA = 0x00000000 0ee7c2b0
[0000000461]   Write FUA: Yes
[0000000461]   World Wide Name: N/A
[0000000461]
[0000000461]   SATA Speed: Gen3
[0000000461]   NCQ Support: Yes
[0000000461]   Queue Depth = 31
[0000000461]
[0000000461]   Logical Sector Size = 512 bytes
[0000000461]   Physical Sector Size = 512 bytes
[0000000461]   Logical Sector Offset = 0
[0000000462]
[0000000462] ================================================

0 Brian Quach over 8 years ago in reply to Brian Quach

TI__Expert 4325 points

Mko,

This appears to work correctly in our testing. Do you have any further feedback?

Regards,
Brian

0 MKo over 8 years ago in reply to Brian Quach

Intellectual 310 points

Hm. Sorry for the late response. Obviously all our mSATA disks then do not report TRIM support correctly. E.g. the innodisk mSATA 3ME3 128GB. That's a pitty.

Nevertheless thanks for your help!

0 Alvina Jennifer over 8 years ago

Prodigy 70 points

Using the ATA TRIM command in real time is inherently more efficient in every situation. Using fstrim, you run into of two situations. Either you run it after too many deletes, and some of your write have to do the whole page-erase-write cycle. Or it runs too often, and the kernel sends duplicate TRIM commands, which need to be examined and ignored.

My only assumption is that the Linux Mint installer isn't able to detect a SSD.

Interface

Interface forum

Linux/TUSB9261: TRIM support in BOT mode