Re: hard crash on leap second
On 2009-01-01 21:26:07 -0700, Paul E Condon wrote:
> On Fri, Jan 02, 2009 at 12:23:18AM +0100, Vincent Lefevre wrote:
> > I agree that sudden jumps or extended periods of stasis are bad.
> > However this is how leap seconds currently work (it would have been
> > better to have a continuous synchronization between UTC and UT1[*]).
> > The consequence is that a machine using chrony can have 1 second
> > difference with other machines. When the files are stored remotely
> > (e.g. on a NFS server), this can yield problems, especially with
> > tools like "make" (even though one doesn't like tools based on
> > timestamps).
>
> When doing a build on a remote host I think one should use time stamps
> that were generated on that remote host.
This is not as simple: files can come from both the remote host (NFS
server) and the local disk, and it isn't always easy to avoid that.
It is even not always possible to use the time of the remote host
(e.g. because files have been transfered by ssh or some other mean).
> It strikes me a very risky to have a bunch of build objects
> scattered across a world wide array of hosts and relying on locally
> generated timestamps to make sure they are in sync. It seems to me
> that there must be a central authority, a single host that assigns
> timestamps to all shared files.
It would be easier not to use timestamps at all.
> > [*] According to Wikipedia, a vote towards this solution was planned
> > in 2008. But Wikipedia is not up-to-date.
>
> I think there are fundamental, irreconsilable differences. Atomic clocks
> and the Earth actually run at different rates, and the difference is
> growing with time.
I don't think this is a problem if almost-real-time corrections are
applied.
> For finding pairs of files that are actually identical, one should use
> a message digest such as md5sum. Time stamp is used only because it's
> easy. Isn't it possible to specify that timestamps be preserved in a
> file copy?
Not with all file systems.
> A preserved timestamp is surely not rewritten during copy to
> compensate for a mismatch in the time settings of the clocks on the
> two computers. So in a system that uses timestamps, if the
> timestamps differ, then, at the very least the copy was not done
> correctly.
One generally needs more than deciding that some file is the same as
the other: some file has been built after some other file.
> In comparing timestamps there is a shoddiness in the kernel. If a file
> is open, its timestamp is reported in kernel-time which is carried to
> a precision of 1 nanosecond (1e-9sec). This precision is actually
> meaningless, but at least it discourages developers from testing for
> equality. When the file is closed, the reported time stamp is the
> number that is recorded in the inode on disk, currently accurate to
> a whole second.
Well, kernel time is not just used for file timestamps. It can be used
for benchmarking, and only the relative accuracy is important (i.e. the
difference between two times).
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Reply to: