[lkml]   [2011]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Nanosecond fs timestamp support: sad
    As an FYI, Lustre uses i_version to store the transaction number in which a file changed. It sets the i_version itself. If NFSv4 were to set i_version when it needs to transition the state of a file then it wouldn't cause overhead on filesystems that are not being used for NFS export.

    I don't think timestamps can ever be completely safe for distributed state management, unless the kernel bends the rules on what a timestamp IS, e.g. by never reverting the ctime when the clock moves backward and such.

    Cheers, Andreas

    On 2011-07-22, at 4:59 PM, NeilBrown <> wrote:

    > On Fri, 22 Jul 2011 18:31:58 -0400 "J. Bruce Fields" <>
    > wrote:
    >> On Fri, Jul 22, 2011 at 06:10:39PM -0400, bfields wrote:
    >>> On Fri, Jul 22, 2011 at 11:47:32PM +0200, Andi Kleen wrote:
    >>>> On Fri, Jul 22, 2011 at 04:11:42PM -0500, Matt Mackall wrote:
    >>>>> On Fri, 2011-07-22 at 22:59 +0200, Andi Kleen wrote:
    >>>>>>> Indeed. Only usefully exists on ext4 and requires extra system calls.
    >>>>>> Not sure what you mean? It's in stat(2), just like the timestamps.
    >>>>> I don't see anything that looks like a version or generation number in
    >>>>> either the man pages, the asm-generic/stat.h, or glibc's asm/stat.h.
    >>>>> Pointer?
    >>>> Hmm you're right. I thought it was in there, but apparently not.
    >>>> I think it should be added there though. We still have some unused
    >>>> fields.
    >>> But last I checked I thought it was only ext4 that actually incremented
    >>> the i_version on IO, and even then only when given a (non-default) mount
    >>> option.
    >>> My notes on what needs to be done there:
    >>> - collect data to determine whether turning on i_version causes
    >>> any significant performance regressions.
    >>> - Last I talked to him, Ted Tso recommended running
    >>> Bonnie on a local disk, since it does a lot of little
    >>> writes, which is somewhat of a worst case, as it will
    >>> generate extra metadata updates for each write.
    >>> Compare total wall-clock time, number of iops, and
    >>> number of bytes (using some kind of block tracing).
    >>> - If there aren't any problems, turn it on by default, and we're
    >>> done.
    >> (Well,and talk the other filesystem implementors into doing it.)
    > But does anyone apart from NFSv4 actually *want* i_version as opposed to the
    > more-generally-useful precise timestamps?
    > If not, we probably should tell NFSv4 to use timestamps and focus on making
    > them work well.
    > ??
    > The timestamp used doesn't need to update ever nanosecond. I think if it
    > were just updated on every userspace->kernel transition (or effective
    > equivalents inside kernel threads) that would be enough capture all
    > causality. I wonder how that would be achieved.. I wonder if RCU machinery
    > could help - doesn't it keep track of when threads schedule ... or something?
    > NeilBrown
    > --
    > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
    > the body of a message to
    > More majordomo info at

     \ /
      Last update: 2011-07-23 03:25    [W:0.046 / U:16.216 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site