From: David Brown <david.brown@hesbynett.no>
To: Jean-Baptiste Thomas <cau2jeaf1honoq@laposte.net>,
Pieter De Wit <pieter@insync.za.net>
Cc: linux-raid@vger.kernel.org
Subject: Re: <DKIM> Re: Paranoid mode for RAID-1 ?
Date: Mon, 27 Apr 2015 12:54:17 +0200 [thread overview]
Message-ID: <553E1559.2010305@hesbynett.no> (raw)
In-Reply-To: <743316986.23005258.1430129889889.JavaMail.zimbra@laposte.net>
On 27/04/15 12:18, Jean-Baptiste Thomas wrote:
> On 2015-04-27 20:45 +1200, Pieter De Wit wrote:
>
>> Sorry for jumping in late - but let's say it does "work" and a
>> drive returns an error, is that data lost ? Or which drive is
>> "right"?
>
> (Assuming that by "returns an error", you mean succeeds but the
> data does not no match what the other(s) returned.)
The alternative interpretation here is that the drive returns an error
message saying it couldn't read the sector - then it's just standard
RAID (get the data from the other disks). So we are looking here at the
extremely rare situation where there is an error but the drive (or
controller) does not detect it.
>
> Let's say there is a setting for how many components must agree.
> If they're not unanimous, read all the other components and look
> for a majority. The components in the minority are flagged
> faulty and the array is degraded but the read succeeds.
>
> If there is no majority, retry a few times. If a majority is
> found, all components which ever were in the minority are
> flagged faulty and the array is degraded but the read succeeds.
>
> If no majority is found, degrade all components, fail the read
> and stop the array. Or whatever is needed to prevent all further
> writes to this array and let the user investigate.
The problem with all of these is that they /might/ be right - but they
/might/ be wrong and make matters worse. Even if you have 3 copies of
the sector, and get two matches and one different, there is no way to
determine that the odd one is wrong. Perhaps a common bus or connector
fault caused the other two to be wrong. Picking the "majority vote" may
decrease your chances of losing data (but may not - it depends on the
cause of the fault), but it certainly does not avoid the worst case
scenario. Perhaps the best choice during normal usage (as distinct from
recovery or rebuild, when the drive is not mounted) is to simply report
a failure to the layers higher up - that way you won't make matters
worse by giving returning data.
Note that the checksum method (used by btrfs and zfs) is different in
that it lets the system know exactly which copy was bad even if the
drive (and bus and controller) think it was good.
next prev parent reply other threads:[~2015-04-27 10:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1610581828.22506051.1430116628556.JavaMail.zimbra@laposte.net>
2015-04-27 6:37 ` Paranoid mode for RAID-1 ? Jean-Baptiste Thomas
2015-04-27 6:48 ` Adam Goryachev
2015-04-27 7:15 ` David Brown
2015-04-27 7:35 ` Mikael Abrahamsson
2015-04-27 8:18 ` Adam Goryachev
2015-04-27 8:34 ` Paranoid mode for RAID-1 ? MD-RAID checksums Pasi Kärkkäinen
2015-04-27 9:15 ` Paranoid mode for RAID-1 ? Roman Mamedov
2015-04-27 6:49 ` NeilBrown
2015-04-27 10:52 ` Jean-Baptiste Thomas
2015-04-27 16:15 ` Wols Lists
2015-04-27 8:45 ` Pieter De Wit
2015-04-27 10:18 ` <DKIM> " Jean-Baptiste Thomas
2015-04-27 10:54 ` David Brown [this message]
2015-04-27 12:36 ` Jean-Baptiste Thomas
2015-04-27 13:46 ` David Brown
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=553E1559.2010305@hesbynett.no \
--to=david.brown@hesbynett.no \
--cc=cau2jeaf1honoq@laposte.net \
--cc=linux-raid@vger.kernel.org \
--cc=pieter@insync.za.net \
/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.