On Thu, 2024-06-27 at 18:13 -0400, Jeff Layton wrote:
> 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.
>
I had a look at this and hit a panic while testing it, but now I'm
wondering if this really needs to be per-namespace. We're stamping
these inodes with values from the realtime clock.
time_namespaces(7) says:
Note that time namespaces do not virtualize the CLOCK_REALTIME
clock. Virtualization of this clock was avoided for reasons of
complexity and overhead within the kernel.
Given that, is making the floor value per-namespace the right thing to
do?
> > 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>
