On Thu, Sep 08, 2022 at 01:40:11PM -0400, Jeff Layton wrote: > > Ted, how would we access this? Maybe we could just add a new (generic) > super_block field for this that ext4 (and other filesystems) could > populate at mount time? Yeah, I was thinking about just adding it to struct super, with some value (perhaps 0 or ~0) meaning that the file system didn't support it. If people were concerned about struct super bloat, we could also add some new function to struct super_ops that would return one or more values that are used rarely by most of the kernel code, and so doesn't need to be in the struct super data structure. I don't have strong feelings one way or another. On another note, my personal opinion is that at least as far as ext4 is concerned, i_version on disk's only use is for NFS's convenience, and so I have absolutely no problem with changing how and when i_version gets updated modulo concerns about impacting performance. That's one of the reasons why being able to update i_version only lazily, so that if we had, say, some workload that was doing O_DIRECT writes followed by fdatasync(), there wouldn't be any obligation to flush the inode out to disk just because we had bumped i_version appeals to me. But aside from that, I don't consider when i_version gets updated on disk, especially what the semantics are after a crash, and if we need to change things so that NFS can be more performant, I'm happy to accomodate. One of the reasons why we implemented the ext4 fast commit feature was to improve performance for NFS workloads. I know some XFS developers have some concerns here, but I just wanted to make it be explicit that (a) I'm not aware of any users who are depending on the i_version on-disk semantics, and (b) if they are depending on something which as far as I'm concerned in an internal implementation detail, we've made no promises to them, and they can get to keep both pieces. :-) This is especially since up until now, there is no supported, portable userspace interface to make i_version available to userspace. Cheers, - Ted
