[lkml]   [2002]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: The return of the return of crunch time (2.5 merge candidate list 1.6)
    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
    - 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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:30    [W:0.053 / U:4.236 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site