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 either. 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
