On Wed, Feb 28, 2024 at 12:30 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > 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, Could I trouble you to suggest a topic for LSFMM to summarize everything that has been going on this year wrt change cookie/time at xfs/vfs level and try to set a clear roadmap? Thanks, Amir.
