I’m very unhappy to find out that M2E1BMU31C doesn’t conform to the SCSI specification (the controller doesn’t report LBPME bit as 1 while it should) thus leading to the TRIM support being unavailable under Linux [without a manual workaround](https://wiki.archlinux.org/title/Solid_state_drive#External_SSD_with_TRIM_support).
There’s no trace of your claim of TRIM support being limited under the Windows OS on either of the product’s specifications and FAQ pages. I literally have to bump into the issue after purchase and then confusingly dig into this forum to find TRIM Support with USB to SATA Cables/Enclosures - StarTech.com IT Pro Community post which is NOT a reasonable degree of research before one considers buying a product.
Please add proper notice and the product page to prevent such nuisance happen again, thank you.
I should mention that the issue is subject to all non-Windows platforms that are claimed as ‘compatible’ on the product page, not just Linux. People buying SSD enclosures expect proper TRIM support to be available as it will affect drive performance after big amounts of data writes, if one has to workaround before gaining the support, it should be clearly marked as such on the product specification page.
I’ve done lots of research on this specific topic as my previous enclosure purchase also has this problem which I put great expectation that this one should fix, while it doesn’t. Please forward this problem to the bridge chip manufacturer to properly conform to all relevant specifications, instead of considering the feature complete if it “works on Windows”.
We don't skip the entire VPD page if LBPME=1, just the parts that are
related to the logical block provisioning.
The reason we read those values in the first place is so that we can set
up discard. If the device signals that it does not support discard we
have had no reason to read them or parse them.
Since there are a plethora of USB-SATA devices out there that get this
incredibly wrong (including discarding blocks *outside* of the specified
block range), I am not going to blindly enable this feature.
If you want to tinker with your own setup that's fine. And you are
clearly capable of doing so.
I, however, have to be extremely cautious not to enable something that
might inadvertently cause data corruption for users out there. That's
all I care about.
If the device manufacturer had intended to support discards then they
would presumably have set the LBPME flag per the spec. And if they
intended to support it but messed up setting the single bit flag that
enables the feature, then I would not trust their implementation.
The root cause of the compatibility issue is that the bridge chip manufacturer didn’t conform to the SCSI specification, not that the operating system doesn’t support the feature. As you’re assumed to be the direct customer of the NVMe to USB bridge solution you should have the right to inform the solution manufacturer that something is wrong with their firmware implementation, not us.
And in the very unfortunate case where your solution provider is incompetent to fix their implementation, it should be clearly mentioned on the product’s specification page, not in a forum post that is nowhere to be found on the product website.
Thank you for sharing your experience with TRIM in Linux on the M2E1BMU31C enclosure. I’ve now updated our online resources to help other customers avoid facing a similar situation in the future.
