Public
Woke up today with completely trashed filesystem on desktop. Spending Birthday re-installing... Thanks Samsung - https://bugs.launchpad.net/ubuntu/+source/fstrim/+bug/1449005 (A bug in their recent SSD firmware for 840 evo)
"As Linux is open source and can be modified by anyone, we do not support Linux. We advise users to disable Queued TRIM in Linux, as doing so will allow Sequential TRIM to run in the OS. .... and have a good day"
Will be my last Samsung SSD bought that's for sure - the firmware update was to workaround another issue with performance degradation... :/
"As Linux is open source and can be modified by anyone, we do not support Linux. We advise users to disable Queued TRIM in Linux, as doing so will allow Sequential TRIM to run in the OS. .... and have a good day"
Will be my last Samsung SSD bought that's for sure - the firmware update was to workaround another issue with performance degradation... :/
From the last post on the launchpad link:
"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?"
I certainly agree with the above paragraph!Jun 2, 2015
:-(Jun 3, 2015- My god. That really is a mess. Most people buying ssd's will use trim. It's a virtually 100% impact rate surely?Jun 3, 2015
- Yeh - if running linux and a kernel without the device blacklisted - If you flash your 840 Evo to the recent firmware (to fix performance issues), the next time the fstrim cronjob (installed by default with ubuntu 15.04 for example), runs, expect major filesystem corruption.
Very serious problem - expect more examples of this as more people upgrade/flash.Jun 3, 2015 
Jun 3, 2015
Thanks +Diego Elio I've seen the issue mentioned in comments on one of those articles about 840 EVO fix, but thought it was just one user who messed his filesystem who knows how. So I bravely booted to linux, and quickly got dmesg full of errors. How stupid of me... luckily the filesystem survived, and it seems I just lost firefox's saved session tabs. So then I went and removed "discard" from fstab :/ I don't know if linux kernel has 840 Evo blacklisted yet, I've found commit doing that from 850 Pro. Stupid Samsung mess...Jun 3, 2015- I'd have thought regressing the firmware would be the best bet. Do they give you the ability to do that? I'd rather have trim than the performance increase.
It's a shame this is a combo Linux and firmware issue if it was windows too there would be such a massive sh1t storm it would be fixed yesterday.Jun 4, 2015 - I don't think you can downgrade the firmware. But you can still have (non-queued) trim if linux kernel blacklists the drive for the falsely advertised queued one.Jun 4, 2015
Add a comment...