public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Lukas Czerner <lczerner@redhat.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: tytso@mit.edu, adilger.kernel@dilger.ca,
	linux-ext4@vger.kernel.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Benjamin Coddington <bcodding@redhat.com>
Subject: Re: should we make "-o iversion" the default on ext4 ?
Date: Wed, 20 Jul 2022 17:22:57 +0200	[thread overview]
Message-ID: <20220720152257.t67grnm4wdi3dpld@fedora> (raw)
In-Reply-To: <ad7218a41fa8ac26911a9ccb79c87609d4279fea.camel@kernel.org>

On Wed, Jul 20, 2022 at 10:38:31AM -0400, Jeff Layton wrote:
> On Wed, 2022-07-20 at 16:15 +0200, Lukas Czerner wrote:

--snip--

> > How would we approach making iversion a default? libmount is passing
> > this option to the kernel as just a MS_I_VERSION flag that is set when
> > -o iversion is used and left empty when the -o noiversion is used. This
> > means that while we could make it a default in ext4, we don't have any
> > way of knowing whether the user asked for -o noiversion. So that's not
> > really an option.
> > 
> > Updating the mke2fs/tune2fs to allow setting iversion as a default mount
> > option I think has the same problem.
> > 
> > So the only way I can see ATM would be to introduce another mountflag
> > for libmount to indicate -o noiversion. This way we can make iversion a
> > default on ext4 without loosing the information about user provided -o
> > noiversion option.
> > 
> > Is there a different way I am not seeing?
> > 
> 
> Right, implementing this is the difficult bit actually since this uses a
> MS_* flag. If we do make this the default, we'd definitely want to
> continue allowing "-o noiversion" to disable it.
> 
> Could we just reverse the default in libmount? It might cause this to
> suddenly be enabled in some deployments, but in most cases, people
> wouldn't even notice and they could still specify -o noiversion to turn
> it off.

Can be done, but that would change the default for everyone. Not sure if
that desirable. Also I can image this being a bit confusing. I still
think the best approach would be to introduce another MS_ flag for
noiversion case. I think there is precedence in the case of
MS_STRICTATIME - not exactly the same but similar enough.

> Another idea would be to introduce new mount options for this, but
> that's kind of nasty from a UI standpoint.
> 
> > 
> > If we can do reasonably extensive testing that will indeed show
> > negligible impact when nothing is querying i_version, then I would be in
> > favor of the change.
> > 
> 
> Excellent! I think that would be best if we can get away with it. A lot
> of people are currently running ext4-backed nfs servers and aren't using
> that mount option.

Could you provide some performance numbers for iversion case?

Thanks!
-Lukas

> -- 
> Jeff Layton <jlayton@kernel.org>
> 


  reply	other threads:[~2022-07-20 15:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-19 13:51 should we make "-o iversion" the default on ext4 ? Jeff Layton
2022-07-20 14:15 ` Lukas Czerner
2022-07-20 14:38   ` Jeff Layton
2022-07-20 15:22     ` Lukas Czerner [this message]
2022-07-20 16:42       ` Jeff Layton
2022-07-21 14:06         ` Lukas Czerner
2022-07-21 17:03           ` Jeff Layton
2022-07-20 15:56     ` Benjamin Coddington
2022-07-20 16:06       ` Christoph Hellwig
2022-07-20 16:15       ` Jeff Layton
2022-07-20 16:29         ` Benjamin Coddington
2022-07-20 16:46           ` Jeff Layton
2022-07-21 22:32 ` Dave Chinner
2022-07-25 16:22   ` Jeff Layton

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=20220720152257.t67grnm4wdi3dpld@fedora \
    --to=lczerner@redhat.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=bcodding@redhat.com \
    --cc=jlayton@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --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