On Thu, 2022-08-25 at 14:48 -0400, Colin Walters wrote: > > On Tue, Aug 23, 2022, at 5:53 PM, Dave Chinner wrote: > > > > THere's no definition of what consitutes an "inode change" and this > > exposes internal filesystem implementation details (i.e. on disk > > format behaviour) directly to userspace. That means when the > > internal filesystem behaviour changes, userspace applications will > > see changes in stat->ino_version changes and potentially break them. > > As a userspace developer (ostree, etc. who is definitely interested in this functionality) I do agree with this concern; but a random drive by comment: would it be helpful to expose iversion (or other bits like this from the vfs) via e.g. debugfs to start? I think that'd unblock writing fstests in the short term right? > > It's great to hear from userland developers who are interested in this! I don't think there is a lot of controversy about the idea of presenting a value like this via statx. The usefulness seems pretty obvious if you've ever had to deal with timestamp granularity issues. The part we're wrestling with now is that applications will need a clear (and testable!) definition of what this value means. We need to be very careful how we define this so that userland developers don't get stuck dealing with semantics that vary per fstype, while still allowing the broadest range of filesystems to support it. My current thinking is to define this such that the reported ino_version MUST change any time that the ctime would change (even if the timestamp doesn't appear to change). That should also catch mtime updates. The part I'm still conflicted about is whether we should allow for a conformant implementation to increment the value even when there is no apparent change to the inode. IOW, should this value mean that something _did_ change in the inode or that something _may_ have changed in it? Implementations that do spurious increments would less than ideal, but defining it that way might allow a broader range of filesystems to present this value. What would you prefer, as a userland developer? -- Jeff Layton <jlayton@xxxxxxxxxx>
