On Wed, 2024-02-28 at 10:46 +1100, Dave Chinner wrote: > On Tue, Feb 27, 2024 at 05:53:46AM -0500, Jeff Layton wrote: > > On Tue, 2024-02-27 at 11:23 +0200, Amir Goldstein wrote: > > > On Tue, Feb 27, 2024 at 4:18 AM Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > And for a new API, wouldn't it be better to use change_cookie (a.k.a i_version)? > > Like xfs_fsr doing online defrag, we really only care about explicit > user data changes here, not internal layout and metadata changes to > the files... > > > > Even if this API is designed to be hoisted out of XFS at some future time, > > > Is there a real need to support it on filesystems that do not support > > > i_version(?) > > > > > > Not to mention the fact that POSIX does not explicitly define how ctime should > > > behave with changes to fiemap (uninitialized extent and all), so who knows > > > how other filesystems may update ctime in those cases. > > > > > > I realize that STATX_CHANGE_COOKIE is currently kernel internal, but > > > it seems that XFS_IOC_EXCHANGE_RANGE is a case where userspace > > > really explicitly requests a bump of i_version on the next change. > > > > > > > > > I agree. Using an opaque change cookie would be a lot nicer from an API > > standpoint, and shouldn't be subject to timestamp granularity issues. > > > > That said, XFS's change cookie is currently broken. Dave C. said he had > > some patches in progress to fix that however. > > By "fix", I meant "remove". > > i.e. the patches I was proposing were to remove SB_I_VERSION support > from XFS so NFS just uses the ctime on XFS because the recent > changes to i_version make it a ctime change counter, not an inode > change counter. > > Then patches were posted for finer grained inode timestamps to allow > everything to use ctime instead of i_version, and with that I > thought NFS was just going to change to ctime for everyone with that > the whole change cookie issue was going away. > > It now sounds like that isn't happening, so I'll just ressurect the > patch to remove published SB_I_VERSION and STATX_CHANGE_COOKIE > support from XFS for now and us XFS people can just go back to > ignoring this problem again. I must have misunderstood what you said when we were at LPC this year: After the multigrain ctime patches were reverted, you mentioned that you were working on a patchset that used the unused bits in the tv_nsec field as counter for counting changes that have occurred within the same tv_nsec value. Did those not pan out for some reason? -- Jeff Layton <jlayton@xxxxxxxxxx>
