Re: The return of the return of crunch time (2.5 merge candidate list 1.6)

[Andi Kleen <ak@suse.de>]

On Sun, Oct 27, 2002 at 10:20:38AM -0500, Andrew Pimlott wrote:
> 
> I'm sure there is a case where this is true, but my imagination and
> googling failed to provide one.  Even the messages to the GNU make

foo: bar
	action1 <something that takes less than a second> 

frob: foo
	action2 <something that takes a long time>


action1 is executed. foo and bar have the same time stamp. action2 
is executed.


make runs again. Default rule sees foo.mtime == bar.mtime and starts
action1 and action2 again. action2 takes a long time. But it's unnecessary,
because bar has not really changed.


> Example problem case (assuming a fs that stores only seconds, and a
> make that uses nanoseconds):
> 
> - I run the "save and build" command while editing foo.c at T = 0.1.
> - foo.o is built at T = 0.2.
> - I do some read-only operations on foo.c (eg, checkin), such that
>   foo.o gets flushed but foo.c stays in memory.
> - I build again.  foo.o is reloaded and has timestamp T = 0, and so
>   gets spuriously rebuilt.

Yes, when you file system has only second resolution then you can get
spurious rebuilds if your inodes get flushed. There is no way my patch
can fix that. While some of the cases may be avoided by better
rounding, it would be better to handle such heuristics in user space
if you really wanted to be clever. Or just make sure you have enough
ram.

The point of my patchkit is to allow the file systems
who support better resolution to handle it properly. Other filesystems
are not worse than before when they flush inodes (and better off when
they keep everything in ram for your build because then they will enjoy 
full time resolution) 

My notes about possible problems with older fs were really not about 
make, but about other programs that could see inconsistencies

It's a fairly obscure case because the inode has to be flushed
and reloaded in less than a second (so not likely to trigger
often in practice) 


> 
> > Another way would be to round on flush, but that also has some problems :-
> > for example you can get timestamps which are ahead of the current
> > wall clock.
> 
> Only if the flush is less than a second after the write, right?
> How likely is that in Linux?

Not very, but could happen in extreme cases.


> 
> I tend to prefer the proposal to set the nanosecond field to 10^9-1.
> At least my scenario above doesn't happen.

If you really wanted that I would recommend to change make.
When all nanosecond parts are 0 it is reasonable for make to assume that
the fs doesn't support finegrained resolution. But I'm not sure it's 
worth it.

-Andi