Bug#1034418: util-linux: fstrim.timer not enabled for upgraded systems
* Matt Taggart [230419 04:22]: > On 4/15/23 15:35, Chris Hofstaedtler wrote: > > > > 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. > > I can think of a few situations: > > A) installed system pre-bullseye, so not enabled by default. System does not > have a /etc/systemd/system/timers.target.wants/fstrim.timer symlink. > 1) admin unaware of it, would benefit from it, might want it > 2) admin aware of it, chose not to not have it enabled > B) installed system bullseye or later, enabled by default. If the system is > lacking the symlink, that means it was explicitly disabled by admin. > > My guess is A1 vastly outnumbers A2 and B, but that those may be non-zero. > Does the differentiation between "disabled" and "masked" make any difference > here? Would an admin that doesn't want it have explicitly masked it? Who knows. I agree it would be nice to have it, but I cannot think of a 100% solution. > I thought of another case where it would be good to have it enabled by > default: for virtual machines that use a copy on write filesystem and set > discard=unmap to tell the virtualization that those blocks can be dropped on > discard, potentially saving a lot of disk space. fstrim.timer not being > enabled in the Debian VM hurts the virtualization host(even those not > running Debian). Yes. Enabling trim/unmap is standard practice for virtualization environments. To get good performance, you have to be in control (or at least be aware) of both the host and the guests, and the underlying storage. > I guess it's already documented in README.Debian. Maybe it would be > interesting to have something in the Bookworm release notes? Makes sense to me. I think the release notes people would want to see a patch / merge request. General advice on how to set up VMs might also want to find a place in the installation guide. Best, Chris
Bug#1034418: util-linux: fstrim.timer not enabled for upgraded systems
On 4/15/23 15:35, Chris Hofstaedtler wrote: 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. I can think of a few situations: A) installed system pre-bullseye, so not enabled by default. System does not have a /etc/systemd/system/timers.target.wants/fstrim.timer symlink. 1) admin unaware of it, would benefit from it, might want it 2) admin aware of it, chose not to not have it enabled B) installed system bullseye or later, enabled by default. If the system is lacking the symlink, that means it was explicitly disabled by admin. My guess is A1 vastly outnumbers A2 and B, but that those may be non-zero. Does the differentiation between "disabled" and "masked" make any difference here? Would an admin that doesn't want it have explicitly masked it? I thought of another case where it would be good to have it enabled by default: for virtual machines that use a copy on write filesystem and set discard=unmap to tell the virtualization that those blocks can be dropped on discard, potentially saving a lot of disk space. fstrim.timer not being enabled in the Debian VM hurts the virtualization host(even those not running Debian). I guess it's already documented in README.Debian. Maybe it would be interesting to have something in the Bookworm release notes? -- Matt Taggart m...@lackof.org
Bug#1034418: util-linux: fstrim.timer not enabled for upgraded systems
* Matt Taggart [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
Bug#1034418: util-linux: fstrim.timer not enabled for upgraded systems
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 NEXTLEFTLAST PASSED UNIT ACTIVATES Mon 2023-04-17 00:23:13 UTC 2 days left n/a n/afstrim.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
