From: Alexander Zarochentcev <zam@namesys.com>
To: reiser@namesys.com
Cc: Nikita Danilov <Nikita@namesys.com>,
Tomas Szepe <szepe@pinerecords.com>,
lkml <linux-kernel@vger.kernel.org>,
Oleg Drokin <green@namesys.com>, umka <umka@namesys.com>
Subject: Re: [BK][PATCH] Reiser4, will double Linux FS performance, pleaseapply
Date: Tue, 5 Nov 2002 11:28:49 +0300 [thread overview]
Message-ID: <15815.33089.583184.62816@crimson.namesys.com> (raw)
In-Reply-To: <3DC773B0.4070701@namesys.com>
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.
next prev parent reply other threads:[~2002-11-05 8:26 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-31 21:23 [BK][PATCH] Reiser4, will double Linux FS performance, please apply Hans Reiser
2002-10-31 22:34 ` Dieter Nützel
2002-10-31 22:47 ` Hans Reiser
2002-11-01 1:17 ` [BK][PATCH] Reiser4, will double Linux FS performance, pleaseapply Andrew Morton
2002-11-01 1:27 ` Andrew Morton
2002-11-01 1:27 ` Hans Reiser
2002-11-01 1:33 ` Andrew Morton
2002-11-01 1:44 ` Dieter Nützel
2002-11-01 1:55 ` Hans Reiser
2002-11-01 10:23 ` Tomas Szepe
2002-11-01 17:19 ` Alexander Zarochentcev
2002-11-02 13:24 ` Tomas Szepe
2002-11-04 11:00 ` Nikita Danilov
2002-11-04 19:56 ` Andreas Dilger
2002-11-05 7:30 ` reiser
2002-11-05 8:28 ` Alexander Zarochentcev [this message]
2002-11-05 8:44 ` reiser
2002-11-05 8:49 ` Alexander Zarochentcev
2002-11-05 21:08 ` reiser
2002-11-05 9:29 ` Andreas Dilger
2002-11-05 21:39 ` reiser
2002-11-05 9:59 ` Tomas Szepe
2002-11-05 10:08 ` Alexander Zarochentcev
2002-11-05 10:23 ` Tomas Szepe
2002-11-05 10:46 ` Nikita Danilov
2002-11-02 13:38 ` Tomas Szepe
2002-11-04 12:02 ` Nikita Danilov
2002-11-04 17:10 ` Tomas Szepe
2002-11-04 17:53 ` Nikita Danilov
2002-11-04 18:10 ` Tomas Szepe
2002-11-01 4:36 ` Linus Torvalds
2002-11-01 10:59 ` Nikita Danilov
[not found] <877555917@toto.iv>
2002-11-05 23:09 ` Peter Chubb
2002-11-06 1:33 ` reiser
2002-11-06 14:25 ` Daniel Egger
2002-11-07 17:19 ` Pavel Machek
2002-11-07 16:58 ` Bill Davidsen
2002-11-06 18:37 Tom Reinhart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15815.33089.583184.62816@crimson.namesys.com \
--to=zam@namesys.com \
--cc=Nikita@namesys.com \
--cc=green@namesys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=reiser@namesys.com \
--cc=szepe@pinerecords.com \
--cc=umka@namesys.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®