Hi,
util-linux includes /usr/lib/systemd/system/fstrim.service, which has
an fstrim.timer set to run the service once per week. It's commonly
enabled by default in linux distributions these days.
By default, fstrim uses the file system block size as the minimum
contiguous free block range for discards. On heavily fragmented file
systems, this can take a while. Whether fragmented or not, such
granularity probably provides no meaningful improvement in wear
leveling performance. I'm wondering if something in the range of 1-4
MiB would be sufficient for most cases, and unlikely to be harmful for
any? Or if block devs have any other ideas for the minimum size?
The tentative proposal is to modify /usr/lib/systemd/system/fstrim.service
- ExecStart=/usr/sbin/fstrim --listed-in
/etc/fstab:/proc/self/mountinfo --verbose --quiet-unsupported
+ ExecStart=/usr/sbin/fstrim --listed-in
/etc/fstab:/proc/self/mountinfo --minimum 4M --verbose
--quiet-unsupported
That results in, e.g.
ioctl(3, FITRIM, {start=0, len=18446744073709551615, minlen=4194304}) = 0
instead of
ioctl(3, FITRIM, {start=0, len=18446744073709551615, minlen=0}) = 0
That this will do much less trimming for particularly heavy use file
systems, so much the better, as drives have been getting quite a bit
smarter about managing wear leveling even without the trim hinting.
But I think it's useful for common consumer devices still out there,
but doesn't need to be so thorough at trimming every free block. Fair?
Best,
--
Chris Murphy
