From: Lukas Czerner <lczerner@redhat.com>
To: Martin Wilck <mwilck@suse.com>
Cc: Jan Kara <jack@suse.cz>, Ted Tso <tytso@mit.edu>,
mwilck@suse.de, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] ext4: Avoid trim error on fs with small groups
Date: Mon, 3 Jan 2022 19:59:40 +0100 [thread overview]
Message-ID: <20220103185940.z5dnjj2shquz7yvg@work> (raw)
In-Reply-To: <ad5272b5b63acf64a47b707d95ecc288d113d637.camel@suse.com>
On Mon, Jan 03, 2022 at 04:34:40PM +0100, Martin Wilck wrote:
> On Mon, 2021-11-22 at 14:53 +0100, Lukas Czerner wrote:
> > On Fri, Nov 19, 2021 at 04:43:53PM +0100, Martin Wilck wrote:
> > > Hi Martin, Lukas,
> > >
> > > On Tue, 2021-11-16 at 23:35 -0500, Martin K. Petersen wrote:
> > >
> >
> > Thanks you Martin P. for clarifying.
> >
> > >
> > > I've checked btrfs and xfs, and they treat the minlen like Jan's
> > > patch
> > > would - the minlen is set to the device's granularity, and
> > > discarding
> > > smaller ranges is silently not even attempted.
> > >
> > > So this seems to be common practice among file system
> > > implementations,
> > > and thus Jan's patch would make ext4 behave like the others. But
> > > I'm
> > > still uncertain if this behavior is ideal, and your remarks seem to
> > > confirm that.
> >
> > Yeah I modeled my change for ext4 on the work in xfs done by
> > Christoph
> > and so it kind of spread organically to other file systems.
>
> Ok. I still believe that it's not ideal this way, but this logic is
> only applied in corner cases AFAICS, so it doesn't really hurt.
>
> I'm fine with Jan's patch for the time being.
>
> >
> > >
> > > The fstrim man page text is highly misleading. "The default value
> > > is
> > > zero, discarding every free block" is obviously wrong, given the
> > > current actual behavior of the major filesystems.
> >
> > Originally there was no discard granularity optimization so it is
> > what
> > it meant.
>
> Not quite. That man page text is from 2019, commit ce3d198d7 ("fstrim:
> document kernel return minlen explicitly"). At that time,
> discard_granularity had existed for 10 years already.
Not really, the sentence you're pointing out above was there from the
beginning. Commit ce3d198d7 didn't change that.
>
>
> > And it also says "fstrim will adjust the minimum if it's
> > smaller than the device's minimum". So I am not sure if it's
> > necessarily
> > misleading.
>
> It is misleading, because it's not fstrim that adjusts anything, but
> the file system code in the kernel.
This makes absolutely no difference from the user POV. Enough nitpicking,
feel free to cc me if you decide to send a patch.
Thanks!
-Lukas
next prev parent reply other threads:[~2022-01-03 18:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20211112152202.26614-1-jack@suse.cz>
[not found] ` <20211115114821.swt3nqtw2pdgahsq@work>
[not found] ` <20211115125141.GD23412@quack2.suse.cz>
[not found] ` <59b60aae9401a043f7d7cec0f8004f2ca7d4f4db.camel@suse.com>
[not found] ` <20211115145312.g4ptf22rl55jf37l@work>
[not found] ` <4e4d1ac7735c38f1395db19b97025bf411982b60.camel@suse.com>
2021-11-16 11:56 ` [PATCH] ext4: Avoid trim error on fs with small groups Lukas Czerner
2021-11-17 4:35 ` Martin K. Petersen
2021-11-19 15:43 ` Martin Wilck
2021-11-22 13:53 ` Lukas Czerner
2022-01-03 15:34 ` Martin Wilck
2022-01-03 18:59 ` Lukas Czerner [this message]
2022-01-04 14:55 ` Jan Kara
2022-01-04 15:05 ` Martin Wilck
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=20220103185940.z5dnjj2shquz7yvg@work \
--to=lczerner@redhat.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mwilck@suse.com \
--cc=mwilck@suse.de \
--cc=tytso@mit.edu \
/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