On Wed, Dec 18, 2019 at 5:12 AM Martin Pitt <mpitt(a)redhat.com> wrote:
Hello Chris,
Chris Murphy [2019-12-17 22:23 -0700]:
> This desktop@ thread [1] about a slow device restored by enabling
> fstrim.service, got me thinking about enabling fstrim.timer [2] by
> default in Fedora Workstation. But I'm curious if it might be
> desirable in other Fedora Editions, and making it a system-wide
> change?
This is a function/property of hardware, so it's IMO not desktop specific at
all. Servers suffer just as well from hard disks becoming slower.
True, although I think the problem is far less likely to happen on
server and cloud hardware, which tend to be suitably overprovisioned
and have better wear leveling algorithms. So for any workload, there's
always erased cells available to accept data at full device speeds,
without either discard mount option or scheduled fstrim. Perhaps
fstrim.timer makes this more efficient? Seems speculative, but for
sure it's safe. At worse, the drive ignores the hint and it's a no op.
> I've checked recent versions of openSUSE and Ubuntu, and they have it
> enabled.
Incidentally I worked on that on the Ubuntu side 6 years ago:
https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming This still
has the "discard vs. cron job" pros and cons and benchmarks, so might still be
useful.
Yes it is. Since that time, the market now has queued trim devices,
and the discard mount option works fine with those. But fstrim.timer
would work fine for all cases, both queued and non-queued.
I suppose it's possible a narrow range of use cases, very heavy writes
and deletions, with queued trim supporting drives, where the discard
mount option is better than fstrim.timer, in that it provides very up
to date hinting of no longer used cells. But it doesn't hurt them to
have both, in the case where the user/admin sets discard mount option
themselves, and are unaware that fstrim.timer is already enabled.
--
Chris Murphy