Linux filesystem development
 help / color / mirror / Atom feed
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


  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