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

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