This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/TUSB9261: TRIM support in BOT mode

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!

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

    Regards,

    Brian

  • 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.

  • 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).

  • 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.

  • 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.
  • 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
  • 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

  • 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

  • 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.

  • 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.

  • 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

  • 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] ================================================

     

  • Mko,

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

    Regards,
    Brian

  • 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!

  • 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.