Bigger picture, I think eventually I'm going to rework stuff related to my use case to be more similar to the container stack, specifically using overlayfs; so it's quite possible by the time iversion is exposed to userspace, I won't have any strong want/need of it myself. On Thu, Aug 25, 2022, at 3:48 PM, Jeff Layton wrote: > IOW, should this value mean that something _did_ change in the inode or > that something _may_ have changed in it? In my case it's basically the same as IMA - we want to only compute the sha256 digest of files that actually changed. Some false positives are hence OK - but that also means the usefulness of the feature degrades in proportion to that number. A bit more detail: I didn't deep dive into the XFS mention about internal/background iversion changes, but AIUI at a high level it sounds like those iversion changes happen mainly (only?) when the file is recently created and pending writeback, which doesn't seem like a problem in practice. I do agree with Ingo's old quote about atime though in https://lwn.net/Articles/244829/ and this thread reminded me to use `noatime` on my main workstation (again; I'd recently changed how I provision it).
