lkml.org 
[lkml]   [2002]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [BK][PATCH] Reiser4, will double Linux FS performance, pleaseapply
    reiser writes:
    > Nikita Danilov wrote:
    >
    > >Tomas Szepe writes:
    > > > > This should help:
    > > > >
    > > > > diff -Nru a/txnmgr.c b/txnmgr.c
    > > > > --- a/txnmgr.c Wed Oct 30 18:58:09 2002
    > > > > +++ b/txnmgr.c Fri Nov 1 20:13:27 2002
    > > > > @@ -1917,7 +1917,7 @@
    > > > > return;
    > > > > }
    > > > >
    > > > > - if (!jnode_is_unformatted) {
    > > > > + if (jnode_is_znode(node)) {
    > > > > if ( /**jnode_get_block(node) &&*/
    > > > > !blocknr_is_fake(jnode_get_block(node))) {
    > > > > /* jnode has assigned real disk block. Put it into
    > > >
    > > >
    > > > Jup, this fixes the leak, but free space still isn't reported accurately
    > > > until after sync gets called, which I believe is a bug too.
    > >
    > >In reiser4 allocation of disk space is delayed to transaction commit. It
    > >is not possible to estimate precisely amount of disk space that will be
    > >allocated during commit, and hence statfs(2) results are not updated
    > >until one does sync(2) (forcing commit) or transaction is committed due
    > >to age (10 minutes by default).
    > >
    > >
    > >
    > The above is badly phrased, and the behavior complained of is indeed a
    > bug not a feature. Please fix.
    >
    > statfs should be updated immediately in accordance with estimates used
    > by the space reservation code, and then adjusted at commit time in
    > accordance with actual usage.

    We should not do that unless we implement forcing of commits at out of free
    space situation.

    >
    > Andreas, the performance advantage is achieved using much more than the
    > amount of RAM available on the computer, and is therefore mostly
    > independent of max transaction age. The appropriate setting of
    > transaction max age depends on the user. The setting we chose is
    > appropriate for software developers doing compiles. It is not clear to
    > me yet what the right setting is. Perhaps 3 minutes is more
    > appropriate. I was probably overly influenced by Drew Roselli's
    > statistics on how long the cyle is between rewrites. Her statistics are
    > probably skewed by having lots of CS students using the machines she got
    > her data from. 5 seconds is too short to perform good layout
    > optimization for subsequent reads.
    >
    > Hans
    >

    --
    Alex.
    -
    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    [from the cache]
    ©2003-2011 Jasper Spaans