When Solid State Drives Are Not That Solid
blog.algolia.com
When Solid State Drives Are Not That Solid
1–10 of 123 posts
Re: When Solid State Drives Are Not That Solid
#2Pretty disappointing to see some of those Samsung drives on the list, because in some of the other tests/surveys I've seen they seemed to be among the better choices. Sigh I guess Sturgeon's Law applies to SSDs too.
Re: When Solid State Drives Are Not That Solid
#3Originally TRIM was an un-queued command; all writes had to be flushed, then TRIM executed, then writes could continue. This was bad for performance with automatic on-file-delete trim, so everyone wanted a trim command that could be put in the command queue along with writes. Many new drives have this.
It turns out that Samsung 8XX SSDs advertise they support queued trim but it's buggy. The old TRIM command works fine.
https://lkml.org/lkml/2015/6/10/642
There are in fact lots of "quirks lists" and "blacklists" in the kernel and virtually all computers require some workarounds in the linux kernel for some buggy hardware they have. Pretty amazing when you think about it.
EDIT: another closely related example is macbook pro SSDs and NCQ aka native command queuing. They claim they support it, but on many it's buggy. It gets better though; the linux kernel just starting trying to use such functionality by default relatively recently.
https://bugzilla.kernel.org/show_bug.cgi?id=60731
these sort of things are, as you can see, very confusing and frustrating to track down, identify, and find a general fix for
EDIT2: now that I actually read the kernel bugzilla entry further, it's more recently come to light the actual problem with recent macbook pro SSDs is MSI (efficient type of interrupts)
Re: When Solid State Drives Are Not That Solid
#4Can 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.
Re: When Solid State Drives Are Not That Solid
#5Wow, that sucks. Another reason to use ZFS – you’d notice the corrupted files a lot sooner.
Re: When Solid State Drives Are Not That Solid
#6Wow, that sucks. Another reason to use ZFS – you’d notice the corrupted files a lot sooner.
Yup. I was seeing occasional corruption with my SanDisk Extreme Pro's and quite happy that ZFS was able to repair the damage each time.
The problem appears to have gone away following a firmware update, touch wood.
Re: When Solid State Drives Are Not That Solid
#7if one machine failed and failover kicked in correctly, why was the engineer paged?
Re: When Solid State Drives Are Not That Solid
#8Wow, that sucks. Another reason to use ZFS – you’d notice the corrupted files a lot sooner.
Or Btrfs on Linux.
Re: When Solid State Drives Are Not That Solid
#9Can 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.
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).
Re: When Solid State Drives Are Not That Solid
#10if one machine failed and failover kicked in correctly, why was the engineer paged?
I wondered this as well. Valuing your engineers' sleep is important.