Rethinking multi-grain timestamps

Posted Oct 10, 2023 15:47 UTC (Tue) by nim-nim (subscriber, #34454)
In reply to: Rethinking multi-grain timestamps by jlayton
Parent article: Rethinking multi-grain timestamps

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.)