From: Jan Kasprzak <kas@fi.muni.cz>
To: Jaap Crezee <jaap@jcz.nl>
Cc: stefan.huebner@stud.tu-ilmenau.de, Wolfgang Denk <wd@denx.de>,
Roberto Spadim <roberto@spadim.com.br>,
linux-raid@vger.kernel.org
Subject: Re: Optimize RAID0 for max IOPS?
Date: Wed, 19 Jan 2011 10:32:17 +0100 [thread overview]
Message-ID: <20110119093217.GA15700@fi.muni.cz> (raw)
In-Reply-To: <4D36A0F9.6040306@jcz.nl>
Jaap Crezee wrote:
: On 01/19/11 09:18, Stefan /*St0fF*/ Hübner wrote:
: >Am 19.01.2011 08:11, schrieb Wolfgang Denk:
: >Lol - I wouldn't have answered in the first place if I didn't have any
: >expertise. So suit yourself - as you don't bring up any real numbers
: >(remember: you've got the weird setup, you asked, you don't have enough
: >money for the enterprise solution - so ...) nobody who worked with 3ware
: >controllers will believe you.
:
: Here's one: I switched from 3ware hardware based raid to linux software
: raid and I am getting better throughputs. I had a 3ware PCI-X car (don't
: know which type by hearth).
: Okay, to be honest I did not have a (enterprise solution?)
: battery-backup-unit. So probably no write caching...
:
A "me too": 3ware 9550SX with 8 drives, RAID-5. The performance
(especially latency) was very bad. After I switched to the md SW RAID
and lowered the TCQ depth in the 3ware controller to 16[*], the filesystem
and latency feels much faster.
The only problem I had was a poor interaction of the CFQ
iosched with the RAID-5 rebuild process, but I have fixed this
by moving to deadline I/O scheduler.
Another case was the LSI SAS 2008 (I admit it is a pretty low-end
HW RAID controller): 10 disks WD RE4 black 2TB in HW and SW RAID-10
configurations:
time mkfs.ext4 /dev/md0 # SW RAID
real 8m4.783s
user 0m9.255s
sys 2m30.107s
time mkfs.ext4 -F /dev/sdb # HW RAID
real 22m13.503s
user 0m9.763s
sys 2m51.371s
The problem with HW RAID is that today's computers can dedicate tens
of gigabytes to buffer cache, which allows the I/O scheduler to reorder
requests based on latency and other criteria, which no RAID controller
can match, because it cannot see which requests are latency-critical
and which are not.
Also, Linux I/O scheduler works really hard to keep all spindles
busy, while when you fill the TC queue of a HW RAID volume with requests
which maps to one or small number of physical disks, there is no way the
controller can tell "send me more requests, but not from this area
of the HW RAID volume".
[*] 3ware driver is especially bad here, because its default queue
depth is 1024, IIRC, which makes the whole I/O scheduler
with queue size 512 a no-op. Think bufferbloat in the storage area.
--
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/ Journal: http://www.fi.muni.cz/~kas/blog/ |
Please don't top post and in particular don't attach entire digests to your
mail or we'll all soon be using bittorrent to read the list. --Alan Cox
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-01-19 9:32 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-18 21:01 Optimize RAID0 for max IOPS? Wolfgang Denk
2011-01-18 22:18 ` Roberto Spadim
2011-01-19 7:04 ` Wolfgang Denk
2011-01-18 23:15 ` Stefan /*St0fF*/ Hübner
2011-01-19 0:05 ` Roberto Spadim
2011-01-19 7:11 ` Wolfgang Denk
2011-01-19 8:18 ` Stefan /*St0fF*/ Hübner
2011-01-19 8:29 ` Jaap Crezee
2011-01-19 9:32 ` Jan Kasprzak [this message]
2011-01-19 7:10 ` Wolfgang Denk
2011-01-19 19:21 ` Wolfgang Denk
2011-01-19 19:50 ` Roberto Spadim
2011-01-19 22:36 ` Stefan /*St0fF*/ Hübner
2011-01-19 23:09 ` Roberto Spadim
2011-01-19 23:18 ` Roberto Spadim
2011-01-20 2:48 ` Keld Jørn Simonsen
2011-01-20 3:53 ` Roberto Spadim
2011-01-21 19:34 ` Wolfgang Denk
2011-01-21 20:03 ` Roberto Spadim
2011-01-21 20:04 ` Roberto Spadim
2011-01-24 14:40 ` CoolCold
2011-01-24 15:25 ` Justin Piszcz
2011-01-24 15:25 ` Justin Piszcz
2011-01-24 20:48 ` Wolfgang Denk
2011-01-24 20:48 ` Wolfgang Denk
2011-01-24 21:57 ` Wolfgang Denk
2011-01-24 21:57 ` Wolfgang Denk
2011-01-24 23:03 ` Dave Chinner
2011-01-24 23:03 ` Dave Chinner
2011-01-25 7:39 ` Emmanuel Florac
2011-01-25 7:39 ` Emmanuel Florac
2011-01-25 8:36 ` Dave Chinner
2011-01-25 8:36 ` Dave Chinner
2011-01-25 12:45 ` Wolfgang Denk
2011-01-25 12:45 ` Wolfgang Denk
2011-01-25 12:51 ` Emmanuel Florac
2011-01-25 12:51 ` Emmanuel Florac
2011-01-24 20:43 ` Wolfgang Denk
2011-01-25 17:10 ` Christoph Hellwig
2011-01-25 18:41 ` Wolfgang Denk
2011-01-25 21:35 ` Christoph Hellwig
2011-01-26 7:16 ` Wolfgang Denk
2011-01-26 8:32 ` Stan Hoeppner
2011-01-26 8:42 ` Wolfgang Denk
2011-01-26 9:38 ` Christoph Hellwig
2011-01-26 9:41 ` CoolCold
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=20110119093217.GA15700@fi.muni.cz \
--to=kas@fi.muni.cz \
--cc=jaap@jcz.nl \
--cc=linux-raid@vger.kernel.org \
--cc=roberto@spadim.com.br \
--cc=stefan.huebner@stud.tu-ilmenau.de \
--cc=wd@denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.