mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@clusterfs.com>
To: reiser <reiser@namesys.com>
Cc: Nikita Danilov <Nikita@namesys.com>,
	Tomas Szepe <szepe@pinerecords.com>,
	Alexander Zarochentcev <zam@namesys.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 02:29:44 -0700	[thread overview]
Message-ID: <20021105022944.A14575@munet-d.enel.ucalgary.ca> (raw)
In-Reply-To: <3DC773B0.4070701@namesys.com>; from reiser@namesys.com on Mon, Nov 04, 2002 at 11:30:56PM -0800

On Nov 04, 2002  23:30 -0800, reiser wrote:
> 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.

I think the bdflush defaults are (were?) something like 5 seconds for
metadata, and 30 seconds for file data. reiser4 should (if it doesn't
already) use the parameters set by sys_bdflush() to tune the writeout
intervals.

I would think that either:
a) A file was completely written in under 30 seconds (e.g. untar or gcc
   or whatever else you are doing), so deferring allocation and writing
   to disk does not help you at all.
b) A file is continuing to be written for more than 30 seconds that
   has a very large amount of outstanding data which can be committed
   to disk with (probably) the same read optimization quality as any
   larger amount of data.
c) A file is continuing to be written for more than 30 seconds that
   is growing slowly and no matter how long you defer the write you
   will only get an incremental read layout.  Presumably you could do
   something to pre-allocate/reserve a bunch of space at the end of this
   file as it continues to grow.

So, except for the very unusual case of files with lifespans between 30
seconds and 300 seconds, or files that are written to between those
intervals, I would guess that you are not gaining much extra benefit by
deferring the writes another 270 seconds.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

  parent reply	other threads:[~2002-11-05  9:23 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
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 [this message]
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=20021105022944.A14575@munet-d.enel.ucalgary.ca \
    --to=adilger@clusterfs.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 \
    --cc=zam@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®