linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Goswin von Brederlow <goswin-v-b@web.de>
To: Andrew Dunn <andrew.g.dunn@gmail.com>
Cc: Justin Piszcz <jpiszcz@lucidpixels.com>,
	linux-raid@vger.kernel.org, nfbrown@novell.com
Subject: Re: Raid Degradation best practices
Date: Sat, 07 Nov 2009 16:02:12 +0100	[thread overview]
Message-ID: <874op6pedn.fsf@frosties.localdomain> (raw)
In-Reply-To: <4AF57257.7010207@gmail.com> (Andrew Dunn's message of "Sat, 07 Nov 2009 08:12:55 -0500")

Andrew Dunn <andrew.g.dunn@gmail.com> writes:

> I am using RAID6, on 9 WD1001FALS drives.
>
> The VERY important data is backed up to multiple external drives and
> stored at a separate location.
>
> I figured out my issue last night. I had an issue with the array where
> it was doing the silly /dev/md_d0 thing, so when I stopped that and
> started the new one I did '--assume-clean' then when I started copying
> my information back to the array multiple devices dropped out. Their
> SMART information passes just fine, so it must have been the array was
> not clean.

--assume-clean just skips the resync. If the array is actualy not
clean you just get an increased mismatch_cnt when you run a check and
bad data when a disk fails. It never causes a disk to drop out.

> This was my mistake, but in the future when I have a real drive failure
> I was curious to see how you approach that issue.

Having bitmaps helps since when a disk temporarily drops out and you
ad it back you only need to resync the bits that have changed. But
that only reduces the window where another (or a third for raid6) disk
failure is critical. If you get 3 failed disk, temporary or not, at
the same time then your raid6 breaks and you need to put the pices
back together yourself. Depending on each components state you might
have data loss or corruption.

The best thing to do is to make sure your hardware is fit and does not
just drop out for a minute.

MfG
        Goswin

      reply	other threads:[~2009-11-07 15:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-06 12:47 Raid Degradation best practices Andrew Dunn
2009-11-07 11:51 ` Justin Piszcz
2009-11-07 13:12   ` Andrew Dunn
2009-11-07 15:02     ` Goswin von Brederlow [this message]

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=874op6pedn.fsf@frosties.localdomain \
    --to=goswin-v-b@web.de \
    --cc=andrew.g.dunn@gmail.com \
    --cc=jpiszcz@lucidpixels.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=nfbrown@novell.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).