All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.