fstrim.timer

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?

TIA

Hi
You can check the timer status :wink:


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…

Thanks, Malcolm.

Steve

man systemd.time. No time defaults to midnight (00:00:00).

From journal:


erlangen:~ # journalctl -b -1 -u fstrim.service 
-- Logs begin at Sun 2018-08-26 08:48:18 CEST, end at Fri 2019-01-04 08:14:18 CET. --
Jan 03 17:09:20 erlangen systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab...
Jan 03 17:12:49 erlangen fstrim[1880]: /boot/efi: 88.2 MiB (92491776 bytes) trimmed on /dev/nvme0n1p4
Jan 03 17:12:49 erlangen fstrim[1880]: /home-SSD: 184 GiB (197619363840 bytes) trimmed on /dev/sdb4
Jan 03 17:12:49 erlangen fstrim[1880]: /Tumbleweed-SSD: 13.4 GiB (14422794240 bytes) trimmed on /dev/sdb3
Jan 03 17:12:49 erlangen fstrim[1880]: /home: 206.8 GiB (222031929344 bytes) trimmed on /dev/nvme0n1p3
Jan 03 17:12:49 erlangen fstrim[1880]: /: 14.7 GiB (15737827328 bytes) trimmed on /dev/nvme0n1p2
Jan 03 17:12:49 erlangen systemd[1]: Started Discard unused blocks on filesystems from /etc/fstab.
erlangen:~ # 

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 …

Consider whether what you’re now doing best meets your needs.

https://wiki.archlinux.org/index.php/Solid_state_drive#TRIM

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.

TSU

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.

TSU

Hi
Btrfs detects and adjusts the mount options for a ssd;


(rw,relatime,ssd,space_cache,subvolid=nnn,subvol=/@/mountpoint)

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…

Ref: man 5 btrfs and man 5 xfs (/discard)

“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.

Wow, I thought the “trim wars” were over for some years now! Fun to see that there are still high-end discussions on the “topic”…

Hi
It still lurks :slight_smile: 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 :smiley: Now I use an SSD…

On Sat 05 Jan 2019 05:56:03 AM CST, arvidjaar wrote:

malcolmlewis;2890817 Wrote:
> Btrfs detects and adjusts the mount options for a ssd;
> >
Code:

> >
> (rw,relatime,ssd,space_cache,subvolid=nnn,subvol=/@/mountpoint)
>

> >
“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 :wink:


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!

Personally, I only have the systemd “fstrim.timer” service enabled on a Desktop system with an ext4 system partition on a SSD.

  • “OnCalendar=monthly” – IOW fstrim is only run once a month (--01 00:00:00) – usually on booting …

If I had a Btrfs system partition on a SSD then, I would tend to use the systemd “btrfs-trim.timer” service and disable the “fstrim.timer” service …

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.

Saw Avoiding having calendar-interval timers run during boot/wakeup, let hope the patch is accepted and ripples through in Tumbleweed.