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

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

On Tue, 24 Jul 2007, Robin Rosenberg wrote:

Show 9 quoted lines

>
> 27778 time(NULL)                        = 1185268822
> 27778 gettimeofday({1185268822, 953340}, NULL) = 0
> 
> Here CVS sleeps. The amount varies between invocations since it
> only sleeps enough for the seconds to wrap.
> 
> 27778 nanosleep({0, 46660000}, NULL)    = 0
> 27778 time(NULL)                        = 1185268823

Btw, this is *really* dangerous and buggy.

The reason? The CPU real-time clock is very different from whatever clock the filesystems may use.

Filesystems generally do not use the same clock as the CPU does. That's obviously true for things like networked filesystems, but it's actually true even for local filesystems (even on UP) because the CPU "realtime" clock rather expensive and much too exact for them. It does all the fancy NTP date correction etc, and it has all the complex code to actually make sure you don't get any time jumps etc.

So you should basically assume that all filesystems will use a clock that is *close*, but not synchronized with the real-time clock. You have NFS issues, but even locally you'd generally expect the local filesystem to be based on a simply clock that is updated by the timer tick, and is "close enough" to the realtime clock that you get with gettimeofday(). But *not* identical.

So if you sleep for one second, the filesystem times will update by one second, but if you try to *synchronize* to exactly one second, it's not at all certain that the *filesystem* clock will be synchronized to the same second! Time skew is simply a fact of life.

A really obvious example of this is NFS. Anybody who thinks that the NFS times are synchronized to the client real-time clock is just seriously mistaken. They may be close, but they won't be identical.

So I think CVS is simply buggy here. It assumes that "filesystem time" is the same as "CPU time", and while that sounds like an obvious assumption to make, if you think about it for even five seconds (the NFS case above), you realize that it's a totally *buggy* assumption.

In other words: if you want the timestamps on two files to be one second apart, you have to sleep one second in between writing them (or you have to set the time explicitly with "utimes()" or similar). Doing the "optimized sleep" simply DOES NOT WORK.

So CVS is buggy. Big surprise. Film at 11.

Btw, if anybody can think of a similar scenario in git, please holler. We shouldn't have those kinds of bugs.

So the things you generally can depend on:

 - *within* a single filesystem, the clocks should be comparable (ie you 
   can do "stat()" on two files, and compare the date-stamps between the 
   files).

 - the clocks should obviously be "close" to the local realtime. Time skew 
   is a fact of life, but if time skews by more than a big fraction of a 
   second, something is wrong. It's certainly still very possible (NFS 
   with clients not running NTP), but at least at that point a program can 
   validly say "badly maintained network, it's the users problem".

but depending on exact time syncronization is a really really bad idea.

		Linus