On Sat, Sep 23, 2023 at 1:46 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Sat, 2023-09-23 at 10:15 +0300, Amir Goldstein wrote: > > On Fri, Sep 22, 2023 at 8:15 PM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > > > > My initial goal was to implement multigrain timestamps on most major > > > filesystems, so we could present them to userland, and use them for > > > NFSv3, etc. > > > > > > With the current implementation however, we can't guarantee that a file > > > with a coarse grained timestamp modified after one with a fine grained > > > timestamp will always appear to have a later value. This could confuse > > > some programs like make, rsync, find, etc. that depend on strict > > > ordering requirements for timestamps. > > > > > > The goal of this version is more modest: fix XFS' change attribute. > > > XFS's change attribute is bumped on atime updates in addition to other > > > deliberate changes. This makes it unsuitable for export via nfsd. > > > > > > Jan Kara suggested keeping this functionality internal-only for now and > > > plumbing the fine grained timestamps through getattr [1]. This set takes > > > a slightly different approach and has XFS use the fine-grained attr to > > > fake up STATX_CHANGE_COOKIE in its getattr routine itself. > > > > > > While we keep fine-grained timestamps in struct inode, when presenting > > > the timestamps via getattr, we truncate them at a granularity of number > > > of ns per jiffy, > > > > That's not good, because user explicitly set granular mtime would be > > truncated too and booting with different kernels (HZ) would change > > the observed timestamps of files. > > > > Thinking about this some more, I think the first problem is easily > addressable: > > The ctime isn't explicitly settable and with this set, we're already not > truncating the atime. We haven't used any of the extra bits in the mtime > yet, so we could just carve out a flag in there that says "this mtime > was explicitly set and shouldn't be truncated before presentation". > > The second problem (booting to older kernel) is a bit tougher to deal > with however. I'll have to think about that one a bit more. There is a straightforward solution to both these problems - opt in with a mount option to truncate user visible timestamps to 100ns (and not jiffy) resolution as Linus is trying to promote. Thanks, Amir.
