From: ross@lug.udel.edu (Ross Vandegrift)
To: Molle Bestefich <molle.bestefich@gmail.com>
Cc: Rik Herrin <rikherrin@yahoo.com>, linux-raid@vger.kernel.org
Subject: Re: Linux RAID Enterprise-Level Capabilities and If It Supports Raid Level Migration and Online Capacity Expansion
Date: Thu, 22 Dec 2005 10:06:31 -0500 [thread overview]
Message-ID: <20051222150631.GC31400@lug.udel.edu> (raw)
In-Reply-To: <62b0912f0512220431l4d1ec130q137b737c1956ddd9@mail.gmail.com>
On Thu, Dec 22, 2005 at 12:31:25PM +0000, Molle Bestefich wrote:
> Since you say "we", I assume you're part of a very large corporation
> and thus intend to RAID a whole bunch of disks. Go with RAID6 + a
> couple of spares for that. If you intend to use really many disks,
> make multiple arrays. (Not sure whether you can share spares across
> arrays, but I think you can.)
A recent foray through mdadm's code verifies this. If it noticies a
failure and there is a spare, it attempts to migrate the spare to the
array that needs it. Very cool feature!
> I've seen lots of MD tests, but none that covered profiling MD's
> random access performance. So I suppose that most hardware solutions
> will do a lot better than MD here since they have been profiled with
> this in mind.
Well, it depends on the RAID level, disk, configuration, and how
you're using it. In general, RAID 0+1 has better seek properties
because reads can be done independantly from many disks. RAID5 is
always going to be slow because n-1 disks need to all simultaneously
read their stripe, and this can cause spindle contention.
Of course, you lose more space to overhead as RAID 0+1 arrays grow...
--
Ross Vandegrift
ross@lug.udel.edu
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
next prev parent reply other threads:[~2005-12-22 15:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-22 10:07 Linux RAID Enterprise-Level Capabilities and If It Supports Raid Level Migration and Online Capacity Expansion Rik Herrin
2005-12-22 12:31 ` Molle Bestefich
2005-12-22 15:06 ` Ross Vandegrift [this message]
2005-12-22 15:20 ` Molle Bestefich
2005-12-29 11:20 ` Rik Herrin
2005-12-29 18:20 ` H. Peter Anvin
2005-12-22 15:29 ` Lajber Zoltan
2005-12-22 15:36 ` Molle Bestefich
2005-12-22 15:57 ` Lajber Zoltan
2005-12-29 11:30 ` Rik Herrin
2005-12-22 21:37 ` Robert Heinzmann
-- strict thread matches above, loose matches on Subject: below --
2005-12-22 17:07 Andrew Burgess
2005-12-22 20:15 ` John Stoffel
2005-12-22 23:02 ` Lajber Zoltan
2005-12-27 6:46 ` jeane
2005-12-27 6:55 ` Lajber Zoltan
2006-01-04 1:39 ` Dan Stromberg
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=20051222150631.GC31400@lug.udel.edu \
--to=ross@lug.udel.edu \
--cc=linux-raid@vger.kernel.org \
--cc=molle.bestefich@gmail.com \
--cc=rikherrin@yahoo.com \
/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;
as well as URLs for NNTP newsgroup(s).