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>
>
next prev parent 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