lkml.org 
[lkml]   [2011]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Nanosecond fs timestamp support: sad
    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.)

    --b.

    > If there are unfixable problems, consider something
    > more complicated (like turning on i_version automatically when
    > someone asks for it).
    > - We need to check that i_version is also doing something
    > sensible on directory as well as on file inodes.
    > - We also need to think about what it does after reboots. (E.g.
    > what is an nfs server to do if clients see the i_version go
    > backwards (and hence possible repeat old values) after a
    > reboot?)
    > - Double-check the order that data updates and i_version updates
    > are done in. (Ideal would be if they were atomic, but for
    > nfsd's purposes at least it should be adequate if the
    > i_version comes after, and no later than the next commit.)
    >
    > --b.


    \
     
     \ /
      Last update: 2011-07-23 00:35    [W:0.023 / U:61.916 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site