From: Timothy Miller <miller@techsource.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: File system performance, hardware performance, ext3, 3ware RAID1, etc.
Date: Thu, 12 Feb 2004 18:32:31 -0500 [thread overview]
Message-ID: <402C0D0F.6090203@techsource.com> (raw)
I'm attempting to get some idea of how much overhead ext3 causes me on
my workstation at home. Furthermore, I'm trying to determine what sort
of advantage I'm really getting from my 3ware RAID controller (model
7000-2, configured for RAID1) over single disks.
Using iozone, I'm finding an upper bound for disk reads at about 40
megs/sec, which is okay, but no better than single disk. That's
probably expected, since sequential reads can't come off the disk any
faster than the disk spins. RAID1 would show its greatest benefit with
RANDOM reads.
To determine the highest upper bound for sequential read throughput, I
timed a dd of the first gigabyte from /dev/sga (the raw device) to
/dev/null. This showed a throughput of 47meg/sec. This shows that ext3
isn't hurting reads.
For writes, iozone found an upper bound of about 10megs/sec, which is
abysmal. Typically, I'd expect writes to be faster (on a single drive)
than reads, because once the write is sent, you can forget about it.
You don't have to wait around for something to come back, and that
latency for reads can hurt performance. The OS can also buffer writes
and reorder them in order to improve efficiency.
The 3ware has this write cache that you can turn on or off. With it
off, it ensures that writes make it to the disks in order. With it on,
it will reorder writes more efficiently. However, I noticed that the
performance only went up to about 16meg/sec with the cache ON.
For comparison, I would like to estimate the maximum WRITE throughout
for the raw device. But I'm not ready to dump zeros to my working
partitions. I was thinking that I could do this with the SWAP
partition. I could turn off swap and then dd TO the swap partition.
Being on the inner tracks, it won't perform as well as the max for the
drive, but it'll give me a lower bound for raw write throughput to
compare against.
IMPORTANT QUESTION: Is there any metadata anywhere in the swap
partition (when it's not in use) that I need to save before I fill it
with zeros?
Also, what do I use as a source for zeros when writing with dd?
"/dev/zero"?
What's the command? How about this:
time dd if=/dev/zero of=/dev/sga3 bs=1024 count=1024
Will that do it? Should I use an offset to avoid any kind of header or
metadata?
If anyone has numbers for what they get with WD1200JB drives, I'd love
to compare.
Thanks!
next reply other threads:[~2004-02-12 23:25 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-12 23:32 Timothy Miller [this message]
2004-02-13 5:53 ` File system performance, hardware performance, ext3, 3ware RAID1, etc Willy Tarreau
2004-02-13 19:19 ` Timothy Miller
2004-02-13 22:39 ` Willy Tarreau
2004-02-13 23:14 ` Timothy Miller
2004-02-13 19:30 ` Eric D. Mudama
2004-02-13 19:55 ` Linus Torvalds
2004-02-13 20:44 ` John Bradford
2004-02-13 22:45 ` Willy Tarreau
-- strict thread matches above, loose matches on Subject: below --
2004-02-13 12:23 Daniel Blueman
2004-02-13 14:27 ` Jamie Lokier
2004-02-13 14:44 ` Daniel Blueman
2004-02-13 16:15 ` Bartlomiej Zolnierkiewicz
2004-02-13 22:56 ` Timothy Miller
2004-02-14 18:16 Walt H
2004-02-16 17:53 ` Timothy Miller
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=402C0D0F.6090203@techsource.com \
--to=miller@techsource.com \
--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