lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Mon, 25 Jul 2022 12:22:21 -0400
From:   Jeff Layton <>
To:     Dave Chinner <>
        linux-fsdevel <>,, Benjamin Coddington <>
Subject: Re: should we make "-o iversion" the default on ext4 ?

On Fri, 2022-07-22 at 08:32 +1000, Dave Chinner wrote:
> On Tue, Jul 19, 2022 at 09:51:33AM -0400, Jeff Layton wrote:
> > Back in 2018, I did a patchset [1] to rework the inode->i_version
> > counter handling to be much less expensive, particularly when no-one is
> > querying for it.
> Yup, there's zero additional overhead for maintaining i_version in
> XFS when nothing is monitoring it. Updating it comes for free in any
> transaction that modifies the inode, so when writes
> occur i_version gets bumped if timestamps change or allocation is
> required.
> And when something is monitoring it, the overhead is effectively a
> single "timestamp" update for each peek at i_version the monitoring
> agent makes. This is also largely noise....
> > Testing at the time showed that the cost of enabling i_version on ext4
> > was close to 0 when nothing is querying it, but I stopped short of
> > trying to make it the default at the time (mostly out of an abundance of
> > caution). Since then, we still see a steady stream of cache-coherency
> > problems with NFSv4 on ext4 when this option is disabled (e.g. [2]).
> > 
> > Is it time to go ahead and make this option the default on ext4? I don't
> > see a real downside to doing so, though I'm unclear on how we should
> > approach this. Currently the option is twiddled using MS_I_VERSION flag,
> > and it's unclear to me how we can reverse the sense of such a flag.
> XFS only enables SB_I_VERSION based on an on disk format flag - you
> can't turn it on or off by mount options, so it completely ignores
> > Thoughts?
> My 2c is to behave like XFS: ignore the mount option and always turn
> it on.

I'd be fine with that, personally.

They could also couple that with a tune2fs flag or something, so you
could still disable it if it were a problem for some reason.

It's unlikely that anyone will really notice however, so turning it on
unconditionally may be the best place to start.
Jeff Layton <>

Powered by blists - more mailing lists