Re: "prune" prone to clock skew (Re: t3306 failure with v1.7.5-rc1)

Jeff King [off-list ref] writes:

So I don't know that it's worth fixing, nor do I know what your "proper
checks" would be. We could open up commits we're about to prune and
check their timestamps for age. That wouldn't help blobs and trees. For
them, we could make a guess as to their age by seeing if they're
connected to any dangling commits, and using the commit timestamp. But
that will only cover some objects, and it is also still vulnerable to
certain types of clock skew (though it is more robust, since you would
need a client and server with one type writing the objects, and then
another skewed client doing the prune, which is even less likely).

I don't personally think this is worth addressing, but as I was Cc'ed,
I'll try.

If we at least know that the object store is contained within a single
filesystem whose clock is at least guaranteed to monotonically increase,
one possible workaround would be to touch a garbage file and read its
timestamp, instead of grabbing the current time from the local clock, no?

On Fri, Apr 08, 2011 at 11:51:10AM -0700, Junio C Hamano wrote:

I don't personally think this is worth addressing, but as I was Cc'ed,
I'll try.

If we at least know that the object store is contained within a single
filesystem whose clock is at least guaranteed to monotonically increase,
one possible workaround would be to touch a garbage file and read its
timestamp, instead of grabbing the current time from the local clock, no?

Yeah, that is a much more accurate and simpler fix. Like you, I don't
really think it's worth worrying about, but if somebody wanted to, that
is much better than the fix I mentioned.

-Peff