lists.openwall.net | 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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <7ae8a678f59a49ffeaaa39265d5108135911eeb3.camel@kernel.org> Date: Mon, 25 Jul 2022 12:22:21 -0400 From: Jeff Layton <jlayton@...nel.org> To: Dave Chinner <david@...morbit.com> Cc: tytso@....edu, adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org, linux-fsdevel <linux-fsdevel@...r.kernel.org>, lczerner@...hat.com, Benjamin Coddington <bcodding@...hat.com> 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 > MS_I_VERSION. > > > 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 <jlayton@...nel.org>
Powered by blists - more mailing lists