linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).