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
