linux-kernel - Re: [PATCH v8 0/5] fs: multigrain timestamps for XFS's change

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZRC1pjwKRzLiD6I3@dread.disaster.area>
Date:   Mon, 25 Sep 2023 08:18:14 +1000
From:   Dave Chinner <david@...morbit.com>
To:     Amir Goldstein <amir73il@...il.com>
Cc:     Jeff Layton <jlayton@...nel.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>,
        Chuck Lever <chuck.lever@...cle.com>,
        Neil Brown <neilb@...e.de>,
        Olga Kornievskaia <kolga@...app.com>,
        Dai Ngo <Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>,
        Chandan Babu R <chandan.babu@...cle.com>,
        "Darrick J. Wong" <djwong@...nel.org>, Jan Kara <jack@...e.cz>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Kent Overstreet <kent.overstreet@...ux.dev>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-nfs@...r.kernel.org, linux-xfs@...r.kernel.org
Subject: Re: [PATCH v8 0/5] fs: multigrain timestamps for XFS's change_cookie

On Sat, Sep 23, 2023 at 05:52:36PM +0300, Amir Goldstein wrote:
> On Sat, Sep 23, 2023 at 1:46 PM Jeff Layton <jlayton@...nel.org> 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@...nel.org> 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".
> >
> 
> I thought about this option too.
> But note that the "mtime was explicitly set" flag needs
> to be persisted to disk so you cannot store it in the high nsec bits.
> At least XFS won't store those bits if you use them - they have to
> be translated to an XFS inode flag and I don't know if changing
> XFS on-disk format was on your wish list.

Remember: this multi-grain timestamp thing was an idea to solve the
NFS change attribute problem without requiring *any* filesystem with
sub-jiffie timestamp capability to change their on-disk format to
implement a persistent change attribute that matches the new
requires of the kernel nfsd.

If we now need to change the on-disk format to support
some whacky new timestamp semantic to do this, then people have
completely lost sight of what problem the multi-grain timestamp idea
was supposed to address.

-Dave.
-- 
Dave Chinner
david@...morbit.com