From: Matthias Andree <matthias.andree@gmx.de>
To: Linux-Kernel mailing list <linux-kernel@vger.kernel.org>
Subject: 2.6.4 ext3fs half order of magnitude slower than xfs - bulk write
Date: Mon, 15 Mar 2004 22:47:42 +0100 [thread overview]
Message-ID: <20040315214741.GA5042@merlin.emma.line.org> (raw)
Hi,
I have an application that writes bulky data files in a short time. The
file sizes are 7, 13, 75 and 95 MBytes (total 190); each file is fsynced
after write, the test partitions are otherwise idle. Think gunzip if
you wish, but it isn't gunzip.
The destination partition is on a Maxtor 4K060H3 ATA drive (5400/min, 12
ms seek, UDMA/100 is enabled), with disabled write cache for one test
set and enabled write cache for another. The ext3 partition is on the
outside (hda5) of the xfs partition (hda7).
Either test uses default scheduler settings (anticipatory I/O
scheduler), ATA controller is a VIA 8237, 256 MB RAM of which around 130
MB are used for X11, and idle squid and some idle Perl processes.
For comparison purposes, I have also checked a reiserfs partition on a
7200/min SCSI drive with write cache and tagged command queueing on.
ext3fs runs in the default data=ordered mode for one test and
data=writeback for another. xfs runs in default mode without special
realtime tricks or such. XFS is at least by a factor three faster than
even ext3 -o data=writeback.
real usr system time in seconds
| | | throughput MB/s approx.
ATA ext3 ordered WC on 52 6.3 1.2 3.6
ATA ext3 writeback WC on 46 6.4 1.3 4.1
ATA xfs WC on 15 6.3 .9 12.7
ATA ext3 ordered WC off 172 6.3 1.2 1.1
ATA ext3 writeback WC off 128 6.2 1.3 1.5
ATA xfs WC off 32 6.3 .9 5.9
-----------------------------------------------------------------------------
SCSI reiserfs TCQ on WC on 38 6.8 1.2 5.0
READ performance with hdparm -tT (above is write performance):
Timing buffer-cache reads: 1180 MB in 2.01 seconds = 588.03 MB/sec
Timing buffered disk reads: 98 MB in 3.03 seconds = 32.38 MB/sec
I'd think we can't reach such a value for writes to a real file system.
Watching "vmstat 1" reveals that ext3fs hangs with >= 98% I/O wait for a
long time, something the other FS don't do; the block-out rate is
considerably lower for ext3fs as well. XFS does not hesitate to stuff
down 26,000 blocks in a single second, ext3fs hardly exceeds 700.
What makes ext3fs so much slower than xfs? (Note that even XFS with
write cache on doesn't get close to even half of what one would expect of
such a system.)
--
Matthias Andree
Encrypt your mail: my GnuPG key ID is 0x052E7D95
next reply other threads:[~2004-03-15 21:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-15 21:47 Matthias Andree [this message]
2004-03-15 23:23 ` Andrew Morton
2004-03-16 1:54 ` Matthias Andree
2004-03-18 5:43 ` Andrew Morton
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=20040315214741.GA5042@merlin.emma.line.org \
--to=matthias.andree@gmx.de \
--cc=linux-kernel@vger.kernel.org \
/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®