Originally TRIM was an un-queued command; all writes had to be flushed, then TRIM executed, then writes could continue.

Originally 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)

Posted by ploxiln on Jun 16, 2015, 1:11 AM

Tags

• reliability (Sysadmin)

Related issues

• ⚠️ PHP CVEs. Update required!
• I think RTS could continue to work if someone made a massive leap of faith and put all the modern infra around it that a AAA extraction s...
• RFC: Pluggable SessionDB Provider — PostgreSQL, MySQL, and Beyond
• v2.1.113+ broken on Termux/Android: native binary requires glibc, no JS fallback
• I’m firmly anti-Tahoe and haven’t updated, and I’ve started to find Apple despicable.
• [FEATURE] Link a source control repo as the source for organization skills