Re: NFS--mounted builddirs and detecting clock skew

[Harlan Stenn]

Bob Friesenhahn wrote:
> On Thu, 22 Nov 2007, Harlan Stenn wrote:
> > I *think* I'd be happy with 'clock skew in the build directory'.
> 
>   You mean like
> 
>    CPU -- NFS (Sources + Objects)

This is one case I know I care about.

> or
> 
>         NFS1 (Sources)
>       /
>    CPU
>       \
>         NFS2 (Built Objects)

I haven't used this, but if 'make' on the CPU system will have one idea
of timestamps, and files on NFS1 and/or NFS2 can show clock skew that
will affect how 'make' on CPU runs, then yes.

> or
> 
>         Local Disk (Sources)
>       /
>    CPU
>       \
>         NFS2 (Built Objects)

Again, if 'make' on CPU system will be adversely affected by clock skew
on NFS2 then this should be checked.

> or
> 
>         NFS1 (Sources)
>       /
>    CPU
>       \
>         Local Disk (Built Objects)

As above.

> I use the last one quite often these days but sometimes I use the 
> first.

There seems to be several issues here.  Is the following a usefully
sufficient question to ask:

 If I touch a file now, how far off is the timestamp on the file I touch
 from what I think the time is?

Taking your above examples into consideration, there is the added
complication of "what if srcdir is unwritable?"

> >> When my clocks are a bit off I have noticed that
> >> GNU make sometimes intermittently complains due to the "wandering
> >> clock" problem.
> >
> > I don't see 'wander' (case insensitive) in either the gmake 3.81 or
> > 3.79.1 source trees.
> 
> What I mean is that the condition is borderline detectable so 
> sometimes it is detected and other times not.

Yes, this all boils down to the meaning of "detectable".

At the moment, I am inclined to think that if 'make' will detect it,
then I care.  And this is clearly an insufficient definition.  Perhaps
the 'check-clock-skew' program would have a "useful" default threshhold,
and there could be an option to specify a different threshhold.

H