[kwlug-disc] Installing onto an SSD

[Remi Gauvin]

On 2021-03-10 9:23 p.m., Remi Gauvin wrote:

>>
> 
> Short version: The install should handle it for you.
> 
> Somewhat longer version:


TL:DR: If you have a Samsung SSD and are having trouble with fstrim, or
just want to be safe and avoid a 'feature' that has a long history of
disastrous problems, add, libata.force=noncqtrim to your kernel options.

For grubs, edit the /etc/default/grub file,  find the
GRUB_CMDLINE_LINUX_DEFAULT=   and inert the parameter inside the quotes.
 Save and run update-grub

The Story:

Soo.... this question prompted me to examine my system and find that my
install of Manjero linux did not, in fact, include a scheduled fstrim
(or much of anything, really.).  I have been operating my new computer
for several months without the benefit of trim.

As soon as tried running the command, however, I would freeze my
computer for for several (over 10) minutes.  After much trial and error,
I concluded that this was the result of Queued Trim.

History (paraphrased from memory, mistakes are expected:)

Queued Trim is a feature that Some SSD's claim to support that allows
trim commands to be queued with the other write commands on SSD.
Withouy Queued Trim, any trim command will block the drive until the
command completes, potentially having very grave performance effects if
lots of small chunks of data are being deleted and trimmed.  This is one
of the main reasons why almost all Linux distros used a scheduled batch
fstrim command instead of mounting ssd's with the 'discard' option.

Linux was very quick to implement Queued Trim, but it's important to
note here: Neither Windows nor Macs use this feature, so linux users
were the first to find several implementation bugs with different models
of SSD's.  The kernel quickly implemented a Blacklist that includes most
(at some point, I think all) Samsung SSD's.

Unknown to me, at some point around 2018, Samsung reached out and
claimed Queued Trim was safe to use with their 860 EVO/Pro drives, so
those were excluded from the blacklist.
Even though people have been reporting problems with it ever since, the
problem reports remain too inconsistent, (depends on chipsets of the
Sata controller, firmware versions, etc maybe.)  Even though Queued Trim
has no performance benefit for distros using the batch trim jobs (all of
them,) and has a history of exposing filesystem destroying bugs, the
kernel maintainer refuses to re-add these Samsung SSD's to the
blacklist.  Personally, this is a feature I would rather disable across
the board.