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.
