On Thu, 2022-08-18 at 11:52 +1000, NeilBrown wrote: > On Thu, 18 Aug 2022, Dave Chinner wrote: > > > > > Maybe we should just go back to using ctime. ctime is *exactly* > > > what > > > NFSv4 wants, as long as its granularity is sufficient to catch > > > every > > > single change. Presumably XFS doesn't try to ensure this. How > > > hard > > > would it be to get any ctime update to add at least one > > > nanosecond? > > > This would be enabled by a mount option, or possibly be a direct > > > request > > > from nfsd. > > > > We can't rely on ctime to be changed during a modification because > > O_NOCMTIME exists to enable "user invisible" modifications to be > > made. On XFS these still bump iversion, so while they are invisible > > to the user, they are still tracked by the filesystem and anything > > that wants to know if the inode data/metadata changed. > > > > O_NOCMTIME isn't mentioned in the man page, so it doesn't exist :-( > > If they are "user invisible", should they then also be "NFS > invisible"? > I think so. > As I understand it, the purpose of O_NOCMTIME is to allow > optimisations > - do a lot of writes, then update the mtime, thus reducing latency. > I > think it is perfectly reasonable for all of that to be invisible to > NFS. The point is that you can always detect an implicit metadata change by just reading the attribute that changed. The case of an explicit change is different, because the application might be changing the value back to a previous setting. The entire value of ctime is that it allows you to know not to trust any caches when this might be the case because it records the fact that there was an explicit data or metadata change somewhere along the line. By discarding that information about explicit vs implicit changes, XFS is making the i_version less useful to applications that need to cache data and/or metadata. So the real question is: for which real world applications is this behaviour adding value that could not be derived through other means? -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
