On Thu, Aug 18, 2022 at 11:52:12AM +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. Maybe, but now you're making big assumptions about what is being done by those operations. Userspace can write whatever it likes, nothing says that O_NOCMTIME can't change user visible data or metadata. > 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. O_NOCMTIME is used by things like HSMs, file defragmenters, deduplication tools, backup programs, etc to be able to read/write data and manipulate file layout without modifying user visible timestamps. i.e. users shouldn't notice that the online defragmenter defragmented their file. Backup programs shouldn't notice the defragmenter defragmented the file. But having uses of it that don't change user visible data does not mean it can't be used for changing user visible data. Hence we made the defensive assumption that O_NOCMTIME was a mechanism that could be used to hide data changes from forensic analysis. With that in mind, it was important that the change counter captured changes made even when O_NOCMTIME was specified to leave behind a breadcrumb to indicate unexpected changes may had been made to the file. Yeah, we had lots of different requirements for the XFS on-disk change counter when we were considering adding it. NFSv4 was one of the least demanding and least defined requirements; it's taken a *decade* for this atime issue to be noticed, so I really don't think there's anything wrong with how XFs has implemented persistent change counters. What it tells me is that the VFS needs more appropriate atime filtering for NFSv4's change attribute requirements.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
