Re: Classic clock skew problem with Make on NFS
From: Fred Ma (fma_at_doe.carleton.ca)
Date: 03/06/04
- Next message: Tejas Kokje: "blocking connect()"
- Previous message: Barry Margolin: "Re: How to "sleep" or "delay"?"
- In reply to: Barry Margolin: "Re: Classic clock skew problem with Make on NFS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 6 Mar 2004 04:34:48 GMT
Barry Margolin wrote:
>
> > good clean way to deal with this problem, where the
> > clock on the machine that hosts my files differs from
> > the clock on the machine which I'm logged onto. I'm
> > not concerned that make will build things unnecessarily,
> > I'm more worried about the possibility that it won't
> > build things when it should. The solution I've seen
> > is to use "touch", followed either by "make clean" or
> > by removal of all *.o files. Is this the "best" way
> > to deal with the problem? I'm told by my sys admin
> > that we already synchronize our machines, but that
> > doesn't mean that clock skew is eliminated (just
> > because of the very nature of disparate machines and
> > clocks on an NFS). Since make compares time stamps,
> > two machines would still be unsynchronized even if it's
> > by a miniscule amount.
>
> File timestamps are only maintained to the granularity of 1 second in
> Unix. NTP is usually able to synchronize clocks much more closely than
> this (all the clocks should be within milliseconds of each other), so
> you should be OK.
Hmmm. Make is complaining about my source file being 0.58s
in the future (for a small Make file). This is Gnu Make
3.80. I'd like to stick with that if possible. Since the
problem seems to arise with skew times under a second, I was
hoping there was a way around the problem besides trying to
lessen the skew between machines (maybe that's naive). Who
knows how little a skew is good enough. In fact, since time
stamps are changing as Make runs, it would seem better if
Make *can* resolve which files are newer even if their time
stamps are very close to each other, just to ensure that the
proper commands get executed. It would be bad if the skew
or limited timing resolution caused the skipping of a Make
command when it should be run (it can be a complicated Make
file not written by me). I've seen this possiblity alluded
to in my googling about the problem of clock skew over NFS
when using Make.
Normally, I only use complicated Make files when building
freeware, and I avoid the problem by building in the local
/tmp directory. However, I anticipate having to use complex
Make files soon for more than just building freeware. I
will be starting a template Make file from a pretty big
package, to me anyway (it's called SystemC, in case anyone
is curious), and developing my own code on top of that. For
code development, using /tmp is not a good option. Also,
SystemC aside, it would be really nice just to not have to
be on guard about possible pathological outcomes due to
clock skew.
Fred
-- Fred Ma Dept. of Electronics, Carleton University 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6
- Next message: Tejas Kokje: "blocking connect()"
- Previous message: Barry Margolin: "Re: How to "sleep" or "delay"?"
- In reply to: Barry Margolin: "Re: Classic clock skew problem with Make on NFS"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
