Package: util-linux
Version: 2.36.1-8+deb11u1
I recently noticed on my existing bullseye systems that fstrim.timer is
not enabled by default:
=======================================================================
# systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/lib/systemd/system/fstrim.timer; disabled; vendor
preset: enabled)
Active: inactive (dead)
Trigger: n/a
Triggers: ● fstrim.service
Docs: man:fstrim
# systemctl list-timers fstrim.timer
NEXT LEFT LAST PASSED UNIT ACTIVATES
0 timers listed.
Pass --all to see loaded but inactive timers, too.
=======================================================================
Here's what it looks like when I enable it:
=======================================================================
# systemctl enable --now fstrim.timer
Created symlink /etc/systemd/system/timers.target.wants/fstrim.timer →
/lib/systemd/system/fstrim.timer
# systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; vendor
preset: enabled)
Active: active (waiting) since Fri 2023-04-14 16:39:49 UTC; 19s ago
Trigger: Mon 2023-04-17 00:23:13 UTC; 2 days left
Triggers: ● fstrim.service
Docs: man:fstrim
Apr 14 16:39:49 foo systemd[1]: Started Discard unused blocks once a week.
# systemctl list-timers fstrim.timer
NEXT LEFT LAST PASSED UNIT ACTIVATES
Mon 2023-04-17 00:23:13 UTC 2 days left n/a n/a fstrim.timer
fstrim.service
1 timers listed.
Pass --all to see loaded but inactive timers, too.
=======================================================================
It looks this way on all my bullseye systems that were older and
dist-upgraded to bullseye. I only have one system that was installed
directly with bullseye and it appeared to be running there (but maybe I
enabled it by hand at some point and forgot?). I have not checked on
testing/unstable (fresh install or dist-upgrade).
Looking in the Debian changelog I see in the 2.35.1-2 entry:
"* Enable fstrim.timer by default"
and that seems to correspond to this commit:
https://salsa.debian.org/debian/util-linux/-/commit/b0f405a45b6ea0608ecb51e8b8d68ec1715a83e7
which adds:
dh_installsystemd --package=util-linux fstrim.timer
Here is the generated section from postinst:
=======================================================================
# End automatically added section
# Automatically added by dh_installsystemd/13.3.4
if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ] || [ "$1" =
"abort-deconfigure" ] || [ "$1" = "abort-remove" ] ; then
# This will only remove masks created by d-s-h on package removal.
deb-systemd-helper unmask 'fstrim.timer' >/dev/null || true
# was-enabled defaults to true, so new installations run enable.
if deb-systemd-helper --quiet was-enabled 'fstrim.timer'; then
# Enables the unit on first installation, creates new
# symlinks on upgrades if the unit file has changed.
deb-systemd-helper enable 'fstrim.timer' >/dev/null || true
else
# Update the statefile to add new symlinks (if any),
which need to be
# cleaned up on purge. Also remove old symlinks.
deb-systemd-helper update-state 'fstrim.timer'
>/dev/null || true
fi
fi
=======================================================================
So I guess if fstrim.timer was installed at some point but not enabled,
upgrades would "update-state" but not enable the service?
Was fstrim.timer delivered in buster but not enabled?
This behavior might follow the principle of least surprise, but I think
for SSD based systems it is losing out on the benefits of TRIM/discard
(improved i/o latency, flash wear). Given that it only runs once a week,
I think also there is minimal risk (but it might cause a multiple
seconds decrease in i/o speed depending on drive).
Can you think of a way this could be enabled for upgraded systems as well?
Thanks,
--
Matt Taggart
m...@lackof.org
