Re: [PATCH v8 0/5] fs: multigrain timestamps for XFS's change_cookie

[Christian Brauner]

On Tue, Sep 26, 2023 at 08:51:32AM -0400, Jeff Layton wrote:
> On Tue, 2023-09-26 at 14:18 +0200, Christian Brauner wrote:
> > > > If there's no clear users and workloads depending on this other than for
> > > > the sake of NFS then we shouldn't expose this to userspace. We've tried
> > 
> > > 
> > > Some NFS servers run in userspace, and they would a "clear user" of this
> > > functionality.
> > 
> > See my comment above. We did thist mostly for the sake of NFS as there
> > was in itself nothing wrong with timestamps that needed urgent fixing.
> > 
> > The end result has been that we caused a regression for four other major
> > filesystems when they were switched to fine-grained timestamps.
> > 
> > So NFS servers in userspace isn't a sufficient argument to just try
> > again with a slightly tweaked solution but without a wholesale fix of
> > the actual ordering problem. The bar to merge this will naturally be
> > higher the second time around.
> > 
> > That's orthogonal to improving the general timestamp infrastructure in
> > struct inode ofc.
> 
> There are multiple proposals in flight here, and they all sort of
> dovetail on one another. I'm not proposing we expose any changes to the
> timestamps to users in any way, unless we can fix the ordering issues,
> and ensure that we can preserve existing behavior re: utimensat().

Yeah, I know you're aware of that and I'm mostly clarifying the
conditions for this work for the ones not that closely involved.

> I think it's possible to do that, but I'm going to table that work for
> the moment, and finish up the atime/mtime accessor conversions first.

That sounds great.

> That makes experimenting with all of this a lot simpler. I think I can

Oh that's good then.