public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Wolly <wwolly@gmx.net>
To: Andre Pang <ozone@algorithm.com.au>, linux-kernel@vger.kernel.org
Subject: Re: Huge disk performance degradation STILL IN 2.4.10
Date: Tue, 25 Sep 2001 12:00:00 +0200	[thread overview]
Message-ID: <200109251000.MAA00463@enigma.deepspace.net> (raw)
In-Reply-To: <200109211723.TAA00638@enigma.deepspace.net> <200109241505.RAA12224@enigma.deepspace.net> <1001344775.069479.26256.nullmailer@bozar.algorithm.com.au>
In-Reply-To: <1001344775.069479.26256.nullmailer@bozar.algorithm.com.au>

On Monday 24 September 2001 17:19, Andre Pang wrote:
> On Mon, Sep 24, 2001 at 05:05:13PM +0200, Wolly wrote:
> > Okay, I plugged some old hd into my computer and formatted one
> > half with ext2, the other half with reiserfs.  It seems to be
> > definitely a reiserfs issue because I cannot trigger the
> > performance loss (permament hd head positioning) with ext2.
>
> This might sound pedantic, but is ext2 on the first half of your
> hard disk and reiserfs on the second half?  If so, that could skew
> your results.  Try putting the reiserfs in the first half of the
> disk and see if that makes a difference.
>
Well, actually this lead me to another idea: I created a disk image 
on my reiserfs home partition (the one I usually use to trigger the 
problem; note however that I can also reproduce it on my PII-350). 

Firstly, I formatted the image with ext2 and run the file creation script. 
No problems, it works fine. 

Then, I formatted the image with reiserfs and tried the file creation 
script. No problems either.. Strange. 

I doubt it's a fragmentation issue (as kernel-2.4.6 does not have the 
problem and the image file would be fragmented as well). 

Could this be some sort of reiserfs flushing issue? 
<speculation> I mean reiserfs wants to flush the newly created files 
too frequently. If reiserfs is on a disk partition, then this results in 
the performance degradation, if it is on an image, all requests to write 
to the image are cached again (by the reiserfs one level below which 
works fine because there is just manipulation of one large file) and the 
problem does not show up. </speculation>

Okay, as just a few people on the list seem to worry about the issue, 
I spent an hour online and downloaded kernel 2.4.6 + patches for 
2.4.[789] again to see exactly where the problem begins. 

Wolly

  reply	other threads:[~2001-09-25  9:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-21 17:23 Huge disk performance degradation in 2.4.9 Wolly
2001-09-21 23:29 ` Steve Kieu
2001-09-23 23:19 ` Huge disk performance degradation STILL IN 2.4.10 Wolly
2001-09-23 23:55   ` Chris Mason
2001-09-24 15:05     ` Wolly
2001-09-24 15:19       ` Andre Pang
2001-09-25 10:00         ` Wolly [this message]
2001-09-30 21:50           ` Tom Vier

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=200109251000.MAA00463@enigma.deepspace.net \
    --to=wwolly@gmx.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ozone@algorithm.com.au \
    /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