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] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 9 Sep 2022 10:58:00 -0400
From:   "Theodore Ts'o" <>
To:     Jeff Layton <>
Cc:     "J. Bruce Fields" <>, Jan Kara <>,
        NeilBrown <>,,,,,,,,,,,,,,,,,,,,
Subject: Re: [man-pages RFC PATCH v4] statx, inode: document the new

On Fri, Sep 09, 2022 at 10:43:30AM -0400, Jeff Layton wrote:

> In general, we want to bump i_version if the ctime changes. I'm guessing
> that we don't change ctime on a delalloc? If it's not visible to NFS,
> then NFS won't care about it.  We can't project FIEMAP info across the
> wire at this time, so we'd probably like to avoid seeing an i_version
> bump in due to delalloc.

Right, currently nothing user-visible changes when delayed allocation
is resolved; ctime isn't bumped, and i_version shouldn't be bumped

If we crash before delayed allocation is resolved, there might be
cases (mounting with data=writeback is the one which I'm most worried
about, but I haven't experimented to be sure) where the inode might
become a zero-length file after the reboot without i_version or ctime
changing, but given that NFS forces a fsync(2) before it acknowledges
a client request, that shouldn't be an issue for NFS.

This is where as far I'm concerned, for ext4, i_version has only one
customer to keep happy, and it's NFS.  :-)    Now, if we expose i_version
via statx(2), we might need to be a tad bit more careful about what
semantics we guarantee to userspace, especially with respect to what
might be returned before and after a crash recovery.  If we can leave
things such that there is maximal freedom for file system
implementations, that would be my preference.

						- Ted

Powered by blists - more mailing lists