Comment # 6 on bug 1043602 from Stanislav Brabec

Well, the interval was selected by the upstream after a long discussion.

We have no plans to diverge util-linux from the upstream.

If there are new facts about recent SSD discs and there is a statistics about
SSD lifetime and performance with various fstrim setups, please open a new
discussion in the util-linux-ng mailing list (and include people from the
thread below to Cc).


Running fstrim more often has unwanted side effects:

- Running TRIM has performance impact.

- TRIM itself can take long time to complete.

- TRIM can shorten life of the SSD disc.

Better heuristics would be fstrim based on the amount of data written. But
something like that is not yet implemented and not easy to implement.




Here is the reference to the discussion:
http://www.spinics.net/lists/util-linux-ng/msg09133.html


Especially this mail explains the interval:


http://www.spinics.net/lists/util-linux-ng/msg09132.html

From: "Theodore Ts'o" <tytso@xxxxxxx>
Subject: Re: [PATCH] fstrim: add systemd units
Date: Wed, 9 Apr 2014 14:39:54 -0400

For those SSD's that have a problem, "mount -o discard" is a disaster.
Some turn into bricks, others will have a degraded flash cells, many
will cause extremely degraded performance for other processes.

What I usually tell people as far as who ask me for advice is that
once a week is usually sufficient, especially for most desktop and
server systems.  If you are running an extreme workload which is doing
a huge number of random writes, then sure, running fstrim more
frequently, or even using "mount -o discard" might make a lot more
sense --- especially if you are using PCIe attached flash.  But in
those cases, the system administrator might not want be willing to
tolerate the random latencies in performance that might show up when
fstrim is running (for pretty much all SATA and SAS attached SSD's out
there, they don't yet support queued trim, so each trim command
requires draining the NCQ queue, which is why sending trim commands,
whether via "mount -o discard" or via fstrim will incur a performance
penalty to whatever else might be trying to use the disk at the time).

I'll note BTW that even using "fstrim" could potentially brick an
especially inexpensive/trashy SSD, although the vendor for whose drive
had been most commonly accused of promulgating those to the world is
out of business (although there are probably plenty of those SSD's
still in use in various community distros' audiences.)

Cheers,

                        - Ted