[lkml]   [2002]   [Nov]   [8]   [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 Tue, Jan 15, 2002 at 12:44:28PM -0500, Pavel Machek wrote:
    > > 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)
    > What about always rounding down even when inode is
    > in memory? That is both simple and consistent.

    I assume you mean, for filesystems that don't support high
    resolution. That is what I think should be done as well. People
    have gotten along with second resolution all these years, so it's no
    great tragedy to make them continue; plus, it seems like the common
    filesystems will support high resolution soon anyway.

    Paul Eggert listed lots of programs that could be broken if
    timestamps jump around. They could all implement heuristic
    work-arounds, but that would be 1) a miracle and 2) a waste of

    The only issue (as far as I can tell) is knowing when to round.
    Hard-coding a list of filesystems seems reasonable (though even that
    could be wrong if I load a newer filesystem module). Ideally,
    though, you would add a simple hook into the filesystem that asks it
    to round the timestamp for you. This would also accommodate
    filesystems that don't store seconds or nanoseconds, but some other

    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.021 / U:41.832 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site