[adding bug-make, replies can drop automake] On 01/12/2011 03:08 PM, Eric Reischer wrote: > I recently upgraded our NFS fileserver to an ext4 filesystem, and since > then we've been having clock skew warnings from make (3.81). Because > the ext3 filesystem that was previously running on the NFS server didn't > support high-precision timestamps, we didn't have clock skew warnings > because an hourly cron job kept the clocks in relatively close sync. > However, since ext4 does support sub-second timestamps, we're getting > warnings about clock skews on the order of a few milliseconds. I tried > adding our target objects to the .LOW_RESOLUTION_TIME target, however > now we're getting a warning about > > make: *** Warning: .LOW_RESOLUTION_TIME file .lib_deps has a high > resolution time stamp > make: warning: Clock skew detected. Your build may be incomplete. > > Since asking to have system clocks of NFS clients and servers synced to > sub-millisecond precision is a bit excessive, is there a way (or feature > request: could there be a way) to set the threshold for clock skews > either via a runtime Makefile directive, or an environment variable? I > can't see any other way to eliminate these warnings without reverting > back to ext3 (which isn't happening). If it's a hard-coded value, there > should be at least a little room for slop in there (~5 milliseconds?) > due to network lag, etc. Even on a point-to-point network, there's > going to be one-way transit times of a millisecond or two.
This is more likely a make issue than an automake issue. That said, NFS timestamps are indeed a source of pain, and gnulib has recently put in quite a bit of work dealing with timestamp skew across NFS (including code to ignore relatively close timestamps, rather than insist that sub-millisecond differences represent skew); some of that may be worth incorporating into the make code base if it isn't there already. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
