Re: [RFC PATCH 0/3][RESEND] fs: opportunistic high-res file timestamps

[Amir Goldstein]

On Tue, Apr 11, 2023 at 5:38 PM Jeff Layton <jlayton@xxxxxxxxxx> 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.

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@xxxxxxxxxx/
[2] https://lore.kernel.org/linux-fsdevel/?q=LSF+TOPIC+-re+d%3A4.months.ago..