From: Wols Lists <antlists@youngman.org.uk>
To: linux-raid@vger.kernel.org
Cc: nkshirsa@redhat.com
Subject: Re: mdadm - raid6 best practices ?
Date: Fri, 22 Sep 2017 20:24:49 +0100 [thread overview]
Message-ID: <59C56381.3030704@youngman.org.uk> (raw)
In-Reply-To: <20170922182607.1977620-1-songliubraving@fb.com>
On 22/09/17 19:26, Song Liu wrote:
> I would say this is a tradeoff between space overhead (2 parity disks per
> array) and data reliability (mean time before data loss, MTBDL, or MTTF).
> Space overhead is easy to calculate. For MTBDL, there are various of
> documents online, for example:
>
> https://jontse.com/courses/files/cornell/ece5730/Lecture24.pdf
>
> For your questions:
>
>> a) recommended number of disks included in RAID array set?
> I would personally recommend 12 to 15 HDDs per array.
>
My gut feel too was that 84 is an awful lot of disks ...
>> b) Is it possible to include all 84 disks in one array and leave 2 of
> them as host spare?
Do you mean hot spare, or were you thinking of raid-6's two parity disks?
The problem with a hot spare is exactly that - when the array is powered
up, they will be powered up. Yes, with an array that size I guess you
really do want a bunch of hot spares configured, but I'm not sure that's
really a good use of disks. If your main disks are beginning to die, the
spares could easily be going the same way :-(
> It is possible, but not recommended. 84 disks per array really hurts
> reliability.
>
>> c) Is there a raid6 best practices document to refer to ?
> I am not aware of such documents.
>
I don't know as it's really a "best practices" document, but there's a
fair bit in the archaeology section of the website you might find
interesting. More about optimisation and speed tests and stuff, but
because it was all old when we started updating the site last year,
that's why it ended up in archaeology.
One thing you really must do is regular scrubs. And MAKE SURE that you
have lots of active and passive monitoring - it would be oh so easy to
lose three disks the moment the guy on watch gets casual and stops
checking ... I don't have access to the stats off the top of my head,
but with that many disks, losing a couple a month to failures doesn't
seem that far-fetched.
> Hope these help.
>
If you do come across some stuff (or write it yourself :-) please let me
know - this is exactly the stuff that should be on the website if I can
find it.
> Song
Cheers,
Wol
next prev parent reply other threads:[~2017-09-22 19:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-22 3:55 mdadm - raid6 best practices ? Nikhil Kshirsagar
2017-09-22 18:26 ` Song Liu
2017-09-22 19:24 ` Wols Lists [this message]
2017-09-22 21:44 ` John Stoffel
2017-09-23 0:40 ` Stan Hoeppner
2017-09-23 3:22 ` Nikhil Kshirsagar
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=59C56381.3030704@youngman.org.uk \
--to=antlists@youngman.org.uk \
--cc=linux-raid@vger.kernel.org \
--cc=nkshirsa@redhat.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 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.