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. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
