Rethinking multi-grain timestamps [LWN.net]

Rethinking multi-grain timestamps

Posted Oct 9, 2023 17:38 UTC (Mon) by jlayton (subscriber, #31672)
Parent article: Rethinking multi-grain timestamps

> The shape of what comes next might be seen in this series from Jeff Layton, the author of the multi-grain timestamp work.

This set is probably also defunct, as it means that you could use utimensat() to set a timestamp and then not get the same value back when you fetched it. My current approach is to try to advance the apparent coarse grained time whenever a fine grained time is handed out. That should mitigate the problem of seeing out-of-order timestamps that Jon descrbed. This is a major rework though, and probably won't be ready for v6.7.

to post comments

Rethinking multi-grain timestamps

Posted Oct 10, 2023 15:47 UTC (Tue) by nim-nim (subscriber, #34454) [Link] (5 responses)

I don’t think advancing the apparent coarse grained time will work, that will just replace one set of time comparaison errors with another.

Rethinking multi-grain timestamps

Posted Oct 10, 2023 22:24 UTC (Tue) by jlayton (subscriber, #31672) [Link] (4 responses)

I think it will work.

Whenever we stamp a file with a fine-grained timestamp, that time will now become the floor for any further timestamp that is handed out. The revised draft I have of this series works, and it now passes the testcase that was failing before, but it's still quite rough and needs further testing.

Rethinking multi-grain timestamps

Posted Oct 11, 2023 7:52 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (3 responses)

That’s very nice to learn thank you for the info!

But won’t that make any file which timestamp is read after the fine-grained timestamp, newer than files which timestamp has been read before, even though in coarse timestamp world they would have the same timestamp, and may have even been written in a different order ?

Rethinking multi-grain timestamps

Posted Oct 11, 2023 10:25 UTC (Wed) by jlayton (subscriber, #31672) [Link] (2 responses)

I probably didn't explain this very well. When I say "handed out" I meant the clock value being stamped onto the inode, not given out via stat() and friends.

Basically, when we go to update any of the inode's timestamps we'll always grab the coarse-grained timestamp in the kernel for the update, unless someone has viewed it recently, in which case we'll grab a fine-grained timestamp instead. The idea is to update the coarse grained timestamp whenever we hand out a fine-grained one. That avoids the problem described in the article where the timestamps on files updated later appear to be earlier than the fine grained update.

That does make issuing a fine-grained timestamp a bit more expensive though, so some of my current effort is in trying to improve that, and minimizing the number of fine-grained updates that are needed.

Rethinking multi-grain timestamps

Posted Oct 11, 2023 22:55 UTC (Wed) by nijhof (subscriber, #4034) [Link] (1 responses)

How would that work up with multiple coarse - fine - coarse - fine... updates in close succession? If each would have to be later than the previous one, then each coarse timestamp would have to be advanced. And so you could end up with timestamps in the future?

Rethinking multi-grain timestamps

Posted Oct 11, 2023 23:18 UTC (Wed) by jlayton (subscriber, #31672) [Link]

When we talk about a fine grained timestamp, what we mean is one that comes directly from the kernel's internal high-resolution timekeeping. That generally has very fine resolution (~100ns or better) and monotonically increases. We grab that value, calculate and fix up the wallclock time from it and give it out. The coarse grained timestamp is updated approximately every jiffy (once per timer tick) and is just a snapshot of the fine grained timestamp at that time.

So to answer your question, there should be no problem. The idea is to update the apparent coarse-grained timestamp _source_ before returning any fine-grained timestamp. Any later fetch from the timestamp source (coarse or fine), will always be later than or equal to the last fine grained timestamp handed out. That should be good enough to keep "make" happy.

(Note that it's a bit more complex with the way that times are tracked in the timekeeping code, so I'm glossing over some details here.)