Comment 54 for bug 1449005

Turns out this "I support Queued TRIM!" issue is a year old and affected the entire previous generation too:
Discovered by kernel devs in the 840 Pro and 840 Evo: https://bugzilla.kernel.org/show_bug.cgi?id=72341
and also discussed here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1338706

Here is another brand (WD) doing the same thing in late 2013: http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/203508.html

The bottom line is: Samsung SSDs firmware have been updated to SATA 3.2 spec, which includes Queued TRIM, and they advertise that they support it, but in reality the firmware doesn't process those queued trims properly and seems to eat random blocks instead, thus destroying random data.

From what I understand from the first link (see comment 48), these drives set "ATA IDENTIFY's word 77, bit 6" to 1, which means "RECEIVE/SEND FPDMA QUEUED supported". That "FPDMA QUEUED" is the thing used to send a queued TRIM. The firmware does not actually support RECV/SEND FPDMA QUEUED, and just wrongly claims that it does. If you try to retrieve "log 13h" the drive errors out, but the spec says that if RECV/SEND FPDMA is supported then log 13h MUST also be supported. So this is a clear case of Samsung's firmware department ticking a flag for all the shiny SATA 3.2 features, and not actually making sure they implemented them all. Very, very shoddy.

Since this problem affects all modern Samsung SSDs, it's really up to Samsung to fix their firmware. It's NOT up to the operating systems to blacklist misbehaving drives. Are we really gonna have to wait until Windows does Queued TRIM and millions of people lose data, for them to react to their broken firmware?

It has proven futile to talk to Samsung via their regular support contact form. This bug report needs to come from someone with better access to intelligent humans at Samsung (they must exist, right?). I know of only two people with "direct access" to Samsung firmware people:
- Marc Carino < marc.ceeeee [at] gmail.com >, who wrote in kernel.org bug #72341 on 2014-05, that he was reaching out to Samsung's firmware department about the problem.
- Martin K. Petersen from Oracle < martin.petersen [at] oracle.com >, who wrote on the kernel mailing list on 2015-05-04 about contacting Samsung.