On Mon, Oct 28, 2002 at 05:30:04AM +0100, Andi Kleen wrote:
> 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.
Try it:
% cat Makefile
foo: bar
touch foo
frob: foo
sleep 10
touch frob
% rm foo bar frob
% touch bar
% make frob
touch foo
sleep 10
touch frob
% make frob
make: `frob' is up to date.
No problem with this case.
> make runs again. Default rule sees foo.mtime == bar.mtime and starts
> action1 and action2 again.
make is not that broken. (Well, according to one post I googled, it
was in 1970, but it was noticed and fixed, and the fixed behavior
has long been standardized.)
> > 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.
I grant that second-resolution timestamps are broken. But you seem
to misunderstand how make works--the current problem is not that
severe. Whereas your change introduces a different problem that (in
my estimation) is more likely to appear, and will cause mare pain.
I'm saying you're replacing a problem (bad graularity) that
- is well known
- is intuitive
- doesn't cause severe problems in practice (or at least, nobody
has provided an example)
with one (timestamps jumping at unpredictable times) that
- is obscure
- requires knowledge of kernel internals to understand
- will bite people (I claim, and have provided a concrete
example)
- will be wickedly hard to reproduce and diagnose
> The point of my patchkit is to allow the file systems
> who support better resolution to handle it properly.
If that is the point, why not leave the behavior unchanged for other
filesystems? (Other than that it would be a bit more work.)
Doesn't it make sense, on general principles, to be conservative?
> 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)
If that were true, I would agree that it's probably not an issue in
practice. But unless I misunderstand, in the example I gave, the
flush and reload of foo.o can happen any time between the first and
second builds, which could be arbitrarily far apart. So I believe
it's a fairly plausible scenario.
Anyway, this isn't the biggest deal in the world. Maybe I'm wrong
and nobody will ever notice. But it doesn't seem like a good risk
to take.
Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:35 EST