On Tue, 24 Jul 2007, Robin Rosenberg wrote:
>
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
