mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.

  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®