>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.
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
-
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/