Mint does not accommodate SSDs (no TRIM)

[pinumbernumber]

I'm running Linux Mint 17 Cinnamon x64 on a system including a Samsung 840 EVO SSD.

What you did for the problem to happen, and how to reproduce it:
* Install mint on an SSD.
* Observe that the "discard" flag is not used when mounting the volume, meaning online TRIM is not being used.
* I can't find any scheduled fstrim either, although I'm not used to upstart so I may be missing something. In any case, mounting with "discard" is a preferable solution for modern SSDs.

What happened:
* TRIM is not utilised.

What you expected to happen instead:
* TRIM should be utilised by having the volume mounted with the "discard" flag. (Or possibly with a scheduled fstrim, as I believe Ubuntu does, but this is probably not optimal except on old and/or poor quality SSDs which are slow to process online TRIM. On modern SSDs, online trim ("discard") is preferred.)

If the problem happened once, sometimes, or always:
* Always.

====

Manual workarounds:
* Open /etc/fstab as root, add "discard" flag, reboot.

====

Other:
* Although some SSDs (Intel) will work okay without TRIM, others (Samsung) require it or will quickly degrade in performance until it is applied.
* On such systems (which are likely common since the 840 and its EVO successor are bestselling SSDs), users will notice degrading performance without an obvious cause, and it will be difficult to diagnose.

[Michael Webster (miketwebster)]

It's not well-documented, but have a look at this, the contents of your /etc/cron.weekly/fstrim:

#!/bin/sh
# call fstrim-all to trim all mounted file systems which support it
set -e

# This only runs on Intel and Samsung SSDs by default, as some SSDs with faulty
# firmware may encounter data loss problems when running fstrim under high I/O
# load (e. g. https://launchpad.net/bugs/1259829). You can append the
# --no-model-check option here to disable the vendor check and run fstrim on
# all SSD drives.
exec fstrim-all

If you have a Samsung or Intel brand SSD, it's already there, and runs on a schedule, otherwise (and if you're sure your drive is capable), you have to add the --no-model-check flag to this.

This article explains a bit why the discard flag isn't used: http://www.howtogeek.com/176978/ubuntu-doesnt-trim-ssds-by-default-why-not-and-how-to-enable-it-yourself/

[pinumbernumber (pinumbernumber)]

Okay, thanks for that. That entirely invalidates my report, although I do
now wonder if "discard" is still slower with current kernel versions and
post-2011 SSDs. I can't find updated info on the matter.

Keeping the scheduled fstrim is clearly the safer option though. Sorry for
wasting time
On 20 Jun 2014 23:00, "Michael Webster" <email address hidden> wrote:

> It's not well-documented, but have a look at this, the contents of your
> /etc/cron.weekly/fstrim:
>
> #!/bin/sh
> # call fstrim-all to trim all mounted file systems which support it
> set -e
>
> # This only runs on Intel and Samsung SSDs by default, as some SSDs with
> faulty
> # firmware may encounter data loss problems when running fstrim under high
> I/O
> # load (e. g. https://launchpad.net/bugs/1259829). You can append the
> # --no-model-check option here to disable the vendor check and run fstrim
> on
> # all SSD drives.
> exec fstrim-all
>
> If you have a Samsung or Intel brand SSD, it's already there, and runs
> on a schedule, otherwise (and if you're sure your drive is capable), you
> have to add the --no-model-check flag to this.
>
> This article explains a bit why the discard flag isn't used:
> http://www.howtogeek.com/176978/ubuntu-doesnt-trim-ssds-by-default-why-
> not-and-how-to-enable-it-yourself/
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1332720
>
> Title:
> Mint does not accommodate SSDs (no TRIM)
>
> Status in The Linux Mint Distribution:
> New
>
> Bug description:
> I'm running Linux Mint 17 Cinnamon x64 on a system including a Samsung
> 840 EVO SSD.
>
> What you did for the problem to happen, and how to reproduce it:
> * Install mint on an SSD.
> * Observe that the "discard" flag is not used when mounting the volume,
> meaning online TRIM is not being used.
> * I can't find any scheduled fstrim either, although I'm not used to
> upstart so I may be missing something. In any case, mounting with "discard"
> is a preferable solution for modern SSDs.
>
> What happened:
> * TRIM is not utilised.
>
> What you expected to happen instead:
> * TRIM should be utilised by having the volume mounted with the
> "discard" flag. (Or possibly with a scheduled fstrim, as I believe Ubuntu
> does, but this is probably not optimal except on old and/or poor quality
> SSDs which are slow to process online TRIM. On modern SSDs, online trim
> ("discard") is preferred.)
>
> If the problem happened once, sometimes, or always:
> * Always.
>
> ====
>
> Manual workarounds:
> * Open /etc/fstab as root, add "discard" flag, reboot.
>
> ====
>
> Other:
> * Although some SSDs (Intel) will work okay without TRIM, others
> (Samsung) require it or will quickly degrade in performance until it is
> applied.
> * On such systems (which are likely common since the 840 and its EVO
> successor are bestselling SSDs), users will notice degrading performance
> without an obvious cause, and it will be difficult to diagnose.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linuxmint/+bug/1332720/+subscriptions
>

[Michael Webster (miketwebster)]

No waste here - I'm trying to get some release notes added for this. It's pretty obscure now, and should be better-explained (and maybe better-implemented in the near future)

[Peter Curtis (pdcurtis)]

Although this is an old thread there are some additional twists which I would like to add as this is currently where a search for an associated problem brings one and it affects @pinumbernumber and any changes to the release notes @miketwebster makes.

There currently seems to be a problem with a number of the more common SSD drives including most of the Samsung 8xx range when used with Linux kernels later than 3.12 and before 4.0.5 which is to do with the new queued TRIM command allegedly not being implemented correctly in the drives. See https://bugs.launchpad.net/ubuntu/+source/fstrim/+bug/1449005 and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1338706. There is a back-port of the work around which blacklists ‘Queued TRIM’ on the problem drives but as far as I can see it does not cover the default kernels used in 17 17.1 and 17.2 as it was applied at 3.13.0-57.95, 3.16.0-43.58 and 3.19.0-22.22

The result is that there will be an almost inevitable and serious data loss on Samsung SSDs with this problem as TRIM is automatically called by default by a cron job in Mint every week. As far as I can tell it will affect all new 8xx SSDs and earlier ones if the firmware is updated. The Samsung 840 Pro and Evo both have a firmware update which exposes the problem but also improves there performance considerably so many people will unsuspectingly apply it and then kill their system at some random time in the following week.

For information only Linux has implemented the new queued TRIM so Windows systems and Mac OSX are not affected at this time so there is no urgency for Samsung to fix it on new production or provide a firmware update and there approach to Linux is ambiguous.

Mint has chosen the conservative "Don't fix unless broken" approach to kernel updates so the essential kernel update will have to be applied manually. I have not yet investigated when the cron job runs the first time relative to the initial install. If it is immediate the only way round it is to modify /etc/cron.weekly/fstrim from the liveUSB or LiveDVD before the install is run the first time, update the kernel and change it back.

As SSDs are now a favourite update and the Samsung range is a likely candidate I wonder if a suitable kernel update should be made a recommended (level 2) update in 17, 17.1 and 17.2. @clem is aware from a posting I made in the last monthly news and I understand that 17.3 should have an appropriate kernel.

I have a personal interest as I had put a Samsung 850 Evo on order before I found out about the potential problem and then quite by chance! I will add any further information I get when my new machine arrives .

@miketwebster Should I also put in a new bug report as well as my input here?