Message-ID: <e03485c02c6f9fefdaf76e93724978e4874d5442.camel@kernel.org>
Date:   Sat, 15 Apr 2023 08:13:18 -0400
From:   Jeff Layton <jlayton@...nel.org>
To:     Amir Goldstein <amir73il@...il.com>,
        Dave Chinner <david@...morbit.com>
Cc:     Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Hugh Dickins <hughd@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Chuck Lever <chuck.lever@...cle.com>,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-xfs@...r.kernel.org, linux-mm@...ck.org,
        linux-nfs@...r.kernel.org, Josef Bacik <josef@...icpanda.com>
Subject: Re: [RFC PATCH 0/3][RESEND] fs: opportunistic high-res file
 timestamps

On Sat, 2023-04-15 at 14:35 +0300, Amir Goldstein wrote:
> On Tue, Apr 11, 2023 at 5:38 PM Jeff Layton <jlayton@...nel.org> wrote:
> > 
> > (Apologies for the resend, but I didn't send this with a wide enough
> > distribution list originally).
> > 
> > A few weeks ago, during one of the discussions around i_version, Dave
> > Chinner wrote this:
> > 
> > "You've missed the part where I suggested lifting the "nfsd sampled
> > i_version" state into an inode state flag rather than hiding it in
> > the i_version field. At that point, we could optimise away the
> > secondary ctime updates just like you are proposing we do with the
> > i_version updates.  Further, we could also use that state it to
> > decide whether we need to use high resolution timestamps when
> > recording ctime updates - if the nfsd has not sampled the
> > ctime/i_version, we don't need high res timestamps to be recorded
> > for ctime...."
> > 
> > While I don't think we can practically optimize away ctime updates
> > like we do with i_version, I do like the idea of using this scheme to
> > indicate when we need to use a high-res timestamp.
> > 
> > This patchset is a first stab at a scheme to do this. It declares a new
> > i_state flag for this purpose and adds two new vfs-layer functions to
> > implement conditional high-res timestamp fetching. It then converts both
> > tmpfs and xfs to use it.
> > 
> > This seems to behave fine under xfstests, but I haven't yet done
> > any performance testing with it. I wouldn't expect it to create huge
> > regressions though since we're only grabbing high res timestamps after
> > each query.
> > 
> > I like this scheme because we can potentially convert any filesystem to
> > use it. No special storage requirements like with i_version field.  I
> > think it'd potentially improve NFS cache coherency with a whole swath of
> > exportable filesystems, and helps out NFSv3 too.
> > 
> > This is really just a proof-of-concept. There are a number of things we
> > could change:
> > 
> > 1/ We could use the top bit in the tv_sec field as the flag. That'd give
> >    us different flags for ctime and mtime. We also wouldn't need to use
> >    a spinlock.
> > 
> > 2/ We could probably optimize away the high-res timestamp fetch in more
> >    cases. Basically, always do a coarse-grained ts fetch and only fetch
> >    the high-res ts when the QUERIED flag is set and the existing time
> >    hasn't changed.
> > 
> > If this approach looks reasonable, I'll plan to start working on
> > converting more filesystems.
> > 
> > One thing I'm not clear on is how widely available high res timestamps
> > are. Is this something we need to gate on particular CONFIG_* options?
> > 
> > Thoughts?
> 
> Jeff,
> 
> Considering that this proposal is pretty uncontroversial,
> do you still want to discuss/lead a session on i_version changes in LSF/MM?
> 
> I noticed that Chuck listed "timespamt resolution and i_version" as part
> of his NFSD BoF topic proposal [1], but I do not think all of these topics
> can fit in one 30 minute session.
> 

Agreed. I think we'll need an hour for the nfsd BoF.

I probably don't need a full 30 min slot for this topic, between the
nfsd BoF and hallway track.

I've started a TOPIC email for this about 5 times now, and keep deleting
it. I think most of the more controversial bits are pretty much settled
at this point, and the rest (crash resilience) is still too embryonic
for discussion.

I might want a lightning talk at some point about what I'd _really_ like
to do long term with the i_version counter (basically: I want to be able
to do a write that is gated on the i_version not having changed).


> Dave,
> 
> I would like to use this opportunity to invite you and any developers that
> are involved in fs development and not going to attend LSF/MM in-person,
> to join LSF/MM virtually for some sessions that you may be interested in.
> See this lore query [2] for TOPICs proposed this year.
> 
> You can let me know privately which sessions you are interested in
> attending and your time zone and I will do my best to schedule those
> sessions in time slots that would be more convenient for your time zone.
> 
> Obviously, I am referring to FS track sessions.
> Cross track sessions are going to be harder to accommodate,
> but I can try.
> 
> Thanks,
> Amir.
> 
> [1] https://lore.kernel.org/linux-fsdevel/FF0202C3-7500-4BB3-914B-DBAA3E0EA3D7@oracle.com/
> [2] https://lore.kernel.org/linux-fsdevel/?q=LSF+TOPIC+-re+d%3A4.months.ago..

-- 
Jeff Layton <jlayton@...nel.org>

Powered by blists - more mailing lists