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. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
