From: Chris Murphy <lists@colorremedies.com>
To: linux-block@vger.kernel.org
Cc: kzak@redhat.com
Subject: FITRIM minimum block size for weekly usage
Date: Sun, 30 Jan 2022 13:13:52 -0700 [thread overview]
Message-ID: <CAJCQCtRM4Gn_EY_A0Da7qz=MFfmw08+oD=syQEQt=9DrE8_gFw@mail.gmail.com> (raw)
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
reply other threads:[~2022-01-30 20:14 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJCQCtRM4Gn_EY_A0Da7qz=MFfmw08+oD=syQEQt=9DrE8_gFw@mail.gmail.com' \
--to=lists@colorremedies.com \
--cc=kzak@redhat.com \
--cc=linux-block@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).