On Thu, 2024-06-27 at 14:53 -0700, Andi Kleen wrote: > Jeff Layton <jlayton@xxxxxxxxxx> writes: > > > > > > Would it be of any benefit to keep a distinct ctime_floor in each > > > super block instead? > > > > > > > Good question. Dave Chinner suggested the same thing, but I think it's > > a potential problem: > > > > The first series had to be reverted because inodes that had been > > modified in order could appear to be modified in reverse order with the > > right combination of fine and coarse grained timestamps. With the new > > floor value, that's no longer possible, but if we were to make it per- > > sb then it becomes possible again with files in different filesystems. > > > > This sort of timestamp comparison is done by tools like "make", and > > it's rather common to keep built objects in one location and generate > > or copy source files to another. My worry is that managing the floor as > > anything but a global value could cause regressions in those sorts of > > workloads. > > Have you considered the interactions with time name spaces? > > It seems you may need a floor for each, otherwise if the floor is set by > some name space with a more future time the other users lose out. > I have not -- I didn't even realize time namespaces were a thing! I'll look into that, but it sounds like it should be possible to do a floor value per namespace. > Also there's the issue to what happens if time gets set backwards. > Patch #4 has a workarounds for that. The main problem is that we don't want to end up with a floor value that's stuck at some point far in the future (vs. the current clock). This set just disregards any floor value that's more than 6ms in the future, under the assumption that that indicates that the clock has jumped backward. It's not perfect and I'm open to better suggestions for handling this though. -- Jeff Layton <jlayton@xxxxxxxxxx>
