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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 19 Jul 2022 09:51:33 -0400
From:   Jeff Layton <>
        linux-fsdevel <>,, Benjamin Coddington <>
Subject: should we make "-o iversion" the default on ext4 ?

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.

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.



Jeff Layton <>

Powered by blists - more mailing lists