* Matt Taggart <m...@lackof.org> [230414 19:54]: > I recently noticed on my existing bullseye systems that fstrim.timer is not > enabled by default: [..]
> 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?). [..] > 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 Indeed. [..] > Here is the generated section from postinst: [..] > # was-enabled defaults to true, so new installations run enable. > 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? Yes. > 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). Yes. Also it is - to the best of my knowledge - the only way of not destroying possible admin configuration on upgrades. [..] > Can you think of a way this could be enabled for upgraded systems as well? No :-( It seems to follow from our policies that you only get defaults on new installs. Upgrades must be left in some possibly not-that-great state. Chris
