All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Stefan /*St0fF*/ Hübner" <stefan.huebner@stud.tu-ilmenau.de>
To: Shain Miley <SMiley@npr.org>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Subject: Re: Raid 6--best practices
Date: Fri, 20 Jan 2012 08:20:07 +0100	[thread overview]
Message-ID: <4F1915A7.6040906@stud.tu-ilmenau.de> (raw)
In-Reply-To: <CF17461882827E43AD7DF6E471FFA903834EFD7858@EXCHANGE.ads.npr.org>

Hi Shain,

Am 20.01.2012 03:54, schrieb Shain Miley:
> Hello all,
> I have been doing some research into possible alternatives to our
> OpenSolaris/ZFS/Gluster file server.  The main reason behind this is,
> due to RedHat's recent purchase of Gluster, our current configuration
> will no longer be supported and even before the acquisition, the upgrade
> path for the OpenSolaris/ZFS stack was murky at best.
> 
> The current servers in question consist of a total of 48, 2TB drives.
> My thought was that I would setup a total of 6 RAID-6 arrays (each
> containing 7 drives + a spare or a flat 8 drive RAID-6 config) and place
> LVM + XFS on top of that.
> 
> My questions really are:
> 
> a)    What is the maximum number of drives typically seen in a RAID-6
> setup like this?  I noticed when looking at the Backblaze blog, that
> they are using RAID-6 with 15 disks (13 + 2 for parity).  That number seemed 
> kind of high to me....but I was wondering what others on the list thought.
> 
Typically RAID6 Arrays are most optimized with 2^n+2 drives, as in that
case the stripe-size * data-disks adds up to a "good" big-block-size of
a power of 2.  A rule of thumb is to have one redundancy for any 4
disks.  That makes a 6-drive RAID6 over-redundant and a 10-drive RAID6
"best to do".  Next would be an 18-drive RAID6 - which compromizes the
redundancy-rule big time.  So I'd go for a 40-drive RAID60 and see what
to do with the rest of the drives...

> b)    Would you recommend using any specific Linux distro over any other?  
> Right now I am trying to decide between Debian and Ubuntu....but I would be open to 
> any others...if there was a legitimate reason to do so (performance, stability, etc) in terms of the Raid codebase.

This question isn't easy to answer - it depends on your needs.  For
storage systems I typically recommend open-e (www.open-e.com), because
that's what we sell most (see www.exomium.com).  It's also most stable
as open-e does heavy QA on kernel and features.
> 
> Thanks in advance,
> 
> Shain
> 
Hope this was helpful,

Stefan
> --
> 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


  parent reply	other threads:[~2012-01-20  7:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4F173D3D.6070902@npr.org>
     [not found] ` <CF17461882827E43AD7DF6E471FFA903834EFD7853@EXCHANGE.ads.npr.org>
2012-01-20  2:54   ` Raid 6--best practices Shain Miley
2012-01-20  3:06     ` Mathias Burén
2012-01-20  3:16       ` Shain Miley
2012-01-22 23:25         ` linbloke
2012-01-20  5:28     ` Wiliam Colls
2012-01-20  7:20     ` Stefan /*St0fF*/ Hübner [this message]
2012-01-20  8:33     ` Roman Mamedov
2012-01-20 10:24     ` David Brown
2012-01-20 16:53       ` Shain Miley
2012-01-25 12:28         ` Peter Grandi
2012-01-23  6:26       ` Stan Hoeppner

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=4F1915A7.6040906@stud.tu-ilmenau.de \
    --to=stefan.huebner@stud.tu-ilmenau.de \
    --cc=SMiley@npr.org \
    --cc=linux-raid@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 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.