[lvs]

Can someone clarify the article's claim that these Samsung drives are really "broken" as such? We have a few of these on 3.13 and 3.16 kernels and ext4 with no problems. It seems that there must be something unique to their application in order to expose these trim failures.

[ploxiln]

Do you have the "discard" mount option enabled? Do you have a cron job that runs the "fstrim" command? It's possible your systems are not running trim. Or maybe your ext4 filesystems have little activity and you haven't had enough corruption to notice yet :)

Also, some Samsung 800 series drives only gained this bug in a recent firmware update (840 EVO specifically).

[guns]

The 840 EVO joined the club with firmware EXT0DB6Q, which itself is a nasty little hack around a fundamental design problem with the tightly packed NAND cells.

Linux 4.0.5 ships with the patch linked above, but for a while you had to roll with a kernel built from source.

EDIT: The blatant file corruption issues only manifested after updating to firmware EXT0DB6Q.

[Figs]

Is there a list of firmware versions with release dates somewhere? I can't seem to find a changelog.

[kuschku]

So, if I don’t update the firmware of my 840 EVO, I can continue using it with discard?

[ploxiln]

I'm not sure exactly when the first 840 EVO firmware which advertised queued trim support (along with SATA 3.1/3.2 support) was released, but I think that if you last updated firmware (or acquired the drive) before October 2014, you're safe.

However, if you don't update your firmware, you'll suffer from significant performance degradation when reading old files: http://www.anandtech.com/show/9196/samsung-releases-second-8...

[xfalcox]

The old file performance hit is VERY big, I can't overstate the need to upgrade.

[kuschku]

I currently can not notice any performance degradation, and I bought the drive in may 2014, with no further updates. (Unless Arch Linux automatically applies firmware updates, but I doubt that)