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
next prev parent 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