I’ve installed the OS on my new SSD, and I was wondering if anyone knows when fstrim (via fstrim.timer) runs?
I cat fstrim.timer and get:
[Unit]
Description=Discard unused blocks once a week
Documentation=man:fstrim
[Timer]
OnCalendar=weekly
AccuracySec=1h
Persistent=true
[Install]
WantedBy=timers.target
And I see fstrim runs weekly, but no time is indicated. The man page doesn’t say when, either. I’ve set DAILY_TIME to 0100 (so udb will run when I not using the system). I know fstrim discards unused blocks, so if it were to run at 0100, it shouldn’t cause udb any heartburn, right?
systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Sat 2018-12-29 10:11:47 CST; 5 days ago
Trigger: Mon 2019-01-07 00:00:00 CST; 3 days left
Docs: man:fstrim
Dec 29 10:11:47 bert systemd[1]: Started Discard unused blocks once a week.
Think of timers as the new cron, as cron gets deprecated, those jobs will move to systemd timers. One advantage of timers is that you can run jobs with less than 1 minute…
The “when” is resolved from the systemd Timer variables “OnCalendar” and “AccuracySec”:
“OnCalendar” set to ‘weekly’ is shorthand for “Mon --* 00:00:00”.
“AccuracySec” set to ‘1h’ means that, the timer is scheduled to elapse within a time window starting with the time specified in OnCalendar=, …
Therefore, with the default setting, “fstrim” will be run weekly on Monday within the hour following Sunday midnight or, the next boot following that timer expiry …
systemd stores the timer information in the directory “/var/lib/systemd/timers/”.
The time of the empty file “/var/lib/systemd/timers/stamp-fstrim.timer” is the time when the systemd fstrim service was last executed.
Further information may be gleaned from the “systemd.timer” (5) and “systemd.time” (7) man pages …
Periodic Trim
Pros
Ensures TRIM is done
Can be done during dedicated periods of time that doesn’t conflict with LOB apps
Cons
No assurance TRIM job is complete and sufficient
Might conflict with something else running at the scheduled time
Continuous TRIM
Pros
Runs as a low priority process, always
Typically best ensures SSD is ready for writes
Cons
In the very, very unlikely case the machine never stops writing to disk, TRIM may never run
Although usually unnoticeable, it’s possible that heavy TRIM tasks may cause latencies
Bottom line,
For most Users doing common things like email and web surfing, it’s far better to implement continuous TRIM by implementing the discard option in the fstab.
Hi
You need to be careful and review the use case when using other distributions wikis and advise, I would hazard a guess that the openSUSE/SUSE kernel developers are up to speed with things like btrfs and the default mount options for the filesystems selected. Also the discard option does not guarantee that small blocks are trimmed, hence the fstrim batch jobs ensures trim takes place. Perhaps a visit/post to the openSUSE Kernel mailing list with the question may glean additional information more relevant to the openSUSE distribution.
Are there any default mount options for TRIM/discard?
AFAIK, today there are still no default configurations that detect an SSD and apply a TRIM configuration, every person has to do this on their own.
For btrfs the fstrim timer takes care of it all, albeit weekly… which the man page indicates that discard may ignore small blocks to discard, hence leave it to fstrim…
For xfs (which is the /home default) it is recommended not to use discard as the impact is severe and to use the fstrim job…
“ssd” is unrelated to TRIM/discard. It changes internal space allocation algorithm in a way that was believed to be more SSD friendly. Recently there were reports that this algorithm may lead to heavy fragmentation and early out-of-space condition and it is questionable whether it is needed with modern SSD at all. Also heuristic to detect SSD is far from being perfect. It is based on “rotational” flag for device; and kernel will always return “non-rotational” unless it can verify that it is local rotational HDD. So any virtual/SAN/… device will be considered “SSD” in this case.
Hi
It still lurks there are still devices that are blacklisted as well… I did use it a while back with ext4 on a SSD, not bothered to change any of the defaults and systems run fine…
Same here, some Samsung EVO 8xx, some Intels since 2015/16, never thought about it much, have a look at SMART from time to time, no problems with performance yet, most systems running 24/7, but no servers. Installed a 42.x to a USB stick (64 GB USB3 Sandisk, the small one with metal case) and used for surfing 1 year, then system turned to read-only in December Now I use an SSD…
> >
“ssd” is unrelated to TRIM/discard. It changes internal space allocation
algorithm in a way that was believed to be more SSD friendly. Recently
there were reports that this algorithm may lead to heavy fragmentation
and early out-of-space condition and it is questionable whether it is
needed with modern SSD at all. Also heuristic to detect SSD is far from
being perfect. It is based on “rotational” flag for device; and kernel
will always return “non-rotational” unless it can verify that it is
local rotational HDD. So any virtual/SAN/… device will be considered
“SSD” in this case.
Hi
Yes, that was just the defaults as installed, I did read something
about space allocation awhile back… my SSD’s are all older ones now,
but still going fine
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-25.25-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
I have the same things in fstrim.timer as @susesteve (OnCalendar=weekly, AccuracySec=1h, Persistent=true), that is the default in /usr/lib/systemd/system/fstrim.timer
What I do not like about it is that with Persistent=true fstrim will be done next boot if it missed the weekly start because the computer was off.
I tried combining OnBootSec=30min with OnUnitActiveSec=1month but that does not work, the two directives are ORed while I would like to have them ANDed.