[Bglug] [kwlug-disc] Installing onto an SSD

[LP]

Thank you explains a lot


Sent from ProtonMail mobile



\-------- Original Message --------
On Mar. 11, 2021, 9:15 a.m., Remi Gauvin < remi at georgianit.com> wrote:

>
>
>
> 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.
>
> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> Group mailing list
> Group at bglug.ca
> [http://bglug.ca/mailman/listinfo/group\_bglug.ca][http_bglug.ca_mailman_listinfo_group_bglug.ca]
>


[http_bglug.ca_mailman_listinfo_group_bglug.ca]: http://bglug.ca/mailman/listinfo/group_bglug.ca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://bglug.ca/pipermail/group_bglug.ca/attachments/20210311/6f15db07/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://bglug.ca/pipermail/group_bglug.ca/attachments/20210311/6f15db07/attachment.sig>