Re: [PATCH] Add a 1-second sleep to git-cvsexportcommit test

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 24, 2007, 23:19 UTC
Message-ID: <alpine.LFD.0.999.0707241608240.3607@woody.linux-foundation.org>
In-Reply-To: <200707250056.20880.robin.rosenberg.lists@dewire.com>

On Wed, 25 Jul 2007, Robin Rosenberg wrote:

> 
> Having our mind enlightened, I propose this or nothing as a workaround. Since
> cvsexportcommit is really a CVS workaround we might work around some bugs
> in CVS itself while we're at it.

Side note: I think the reason it came up now is that with CONFIG_NO_HZ the Linux filesystem clock will easily be off by half a second even for local filesystems.

With CONFIG_NO_HZ, we don't update the time as religiously, and as a result, people who look at the low-resolution time (like filesystems) will get a noticeable skew.

Quite frankly, that's a Linux kernel bug, and we'll fix it. But it doesn't really invalidate the argument: applications really shouldn't depend on the "filesystem time" being in sync with the "CPU time", and it may be that the kernel bug was the one that ended up exposing this mis-feature of CVS.

Normally, Linux (and probably most other systems) will keep the local filesystems synchronized to within at least one clock-tick of the real-time clock, so the clock skew between filesystems and CPU is at most in the "few millisecond" range.

That's also the kind of range that NTP will largely guarantee, so generally, in most circumstances, while you cannot (and shouldn't) expect filesystem times to be "accurate", in most good situations you'll never see skews over a few milliseconds.

(But on the other hand, search for "kerberos" and "time skew" on google, and you see discussions about allowing five *minutes* of skew etc, so clearly the model of "everybody runs NTP" isn't exactly all of it ;)

So I suspect that the CVS code is (a) buggy and (b) hard to show the bug actually triggering on a well-maintained machine, and that it may well be the case that the only reason it shows up as a bug now is that Jason is running a recent kernel with CONFIG_NO_HZ. I have no idea what the default Fedora 7 kernel does.

		Linus