From: Michael Tokarev <mjt@tls.msk.ru>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: linux-raid <linux-raid@vger.kernel.org>
Subject: Re: stoppind md from kicking out "bad' drives
Date: Mon, 11 Nov 2013 12:05:21 +0400 [thread overview]
Message-ID: <52808FC1.3010200@msgid.tls.msk.ru> (raw)
In-Reply-To: <alpine.DEB.2.02.1311110853530.26054@uplift.swm.pp.se>
11.11.2013 11:56, Mikael Abrahamsson wrote:
> On Mon, 11 Nov 2013, Michael Tokarev wrote:
>
>> No, really, that's not the solutions I was asking for.
>
> Well, it is.
>
>> Yes raid6 is better in this context. But it has exactly the same properties
>> when drives start "semi-failing" - it is enough to have one bad sector in
>> different places of 3 drives for a catastrophic failure, while the array
>> can even continue to work normally because the bad sectors are in different
>> places.
>
> If you have timeouts set properly then md will be able to re-calculate the bad sector from parity and re-write it, even with one drive failed.
Timeouts has nothing to do with this at all.
First drive were "stuck" somewhere in its firmware or electronics and
didn't respond at all (for several MINUTES), even to device reset.
It recovered much later when a bus reset was performed.
Second drive returned "I can't read this data" rather quickly. It
was not "timeout reading" or somesuch, it was a confident "sorry guys
I've lost this piece".
>> It is the drive kick-off - the decision made by md driver - which makes the failure catastrophic.
>
> That's what the timeout problem is. If you're running consumer drives and default linux kernel timeouts then the drive will be kicked before it can return a read error.
It's not consumer drivers, and again, it has nothing to do with the timeouts.
Even if it were really timeouts, even given infinite timeout, if the bad
sector can't be read, no games with timeouts will let to recover it.
And it is just ONE bad sector (on next drive) which makes md to kick the
WHOLE device out of the array -- exactly the moment which turns the issue
from "maybe, just maybe, lost some data" to "whole data has been lost".
(And yes I pretty much understand that md tries to rewrite the place when
it can do that)
[]
> I don't understand why you would be running a RAID5+spare instead of RAID6 without spare.
Yet again, this is a entirely different question.
Please, pretty please, don't speak if you don't understand the topic... ;)
Thanks,
/mjt
next prev parent reply other threads:[~2013-11-11 8:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-11 7:28 stoppind md from kicking out "bad' drives Michael Tokarev
2013-11-11 7:41 ` Mikael Abrahamsson
2013-11-11 7:51 ` Michael Tokarev
2013-11-11 7:56 ` Mikael Abrahamsson
2013-11-11 8:05 ` Michael Tokarev [this message]
[not found] ` <CAPbD+Re7sVfSawjGFyMZMpU4Oaf3ULTW-UA3eoD_upcgxj3GOg@mail.gmail.com>
2013-11-13 15:45 ` Michael Tokarev
2013-11-11 15:55 ` Ian Pilcher
2013-11-23 22:05 ` Michael Tokarev
2013-11-24 23:00 ` NeilBrown
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=52808FC1.3010200@msgid.tls.msk.ru \
--to=mjt@tls.msk.ru \
--cc=linux-raid@vger.kernel.org \
--cc=swmike@swm.pp.se \
/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.