Comment 68 for bug 1449005

Is this the same Problem as described there at https://blog.algolia.com/when-solid-state-drives-are-not-that-solid/ ?

This does affect the 850 EVO also, not just PRO.

Well, the 'bugfix' for 3.16.0-43.58 is there, but somehow the Kernel does not say 'disabling queued TRIM support'
I currently get 'failed to get NCQ Send/Recv Log Emask 0x1'.

Also I am a bit confused, while it may be another issue only i face, since the system currently should be 14.04.2 with an lts-utopic kernel, but the latest kernel uname -a reports, right after an upgrade:

Linux .... 3.16.0-43-generic #58~14.04.1-Ubuntu SMP Mon Jun 22 10:21:20 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

This looks somewhat old by the stated date. Why does aptitude update && aptitude dist-upgrade not upgrade to the Version with the 'bugfix', and why does the Version number indicate a match to the Version with the 'bugfix'?

cat /sys/block/sda/device/queue_depth does report 31

Offtopic:

Does anyone work on detecting or scanning at a low-level (dm, logical volume manager, file-system) for 512 sized and zeroed areas at suspicious places, maybe even telling the maybe corrupted filename? Actually the information I found about fstrim and the real inner workings in combination with volume managers etc. is hard to find.

I would welcome if someone would pick up on the tests that algolia published on github to build some stress tests for ssd in general.

Does it zero out 'random' blocks only when it's under some 'heavy load', or just always?