From: "Brett L. Trotter" <brett@silcon.com>
To: linux-raid@vger.kernel.org
Subject: the true behavior of mdadm's raid-1 with regard to vertical parity and silent error detection/scrubbing- confirmation or feature request
Date: Tue, 17 Aug 2010 22:56:38 -0500 [thread overview]
Message-ID: <4C6B59F6.5020001@silcon.com> (raw)
I've googled endlessly about the internal nature of a md Raid-1.
Over the years, I've found several single bit flips on traditional
platter disks on files that were previously on a linux raid-1 that had
split and while doing a verification of the two copies. This seems to
imply that what I'm looking for doesn't exist- and that is simply a
vertical parity within each disk at the md level- even a single crc32
every once in a while so that if a bit flips on drive 1 of a mirror,
drive 2's copy replaces it instead of 1's bit flipped copy replacing
drive 2's good copy. From what I can gather, it seems to be a 50/50 shot
whether your good copy gets mangled in the event of a silent bit flippage.
So- is there any built in parity that helps mdadm decide which copy to
use when the copies disagree on a raid 1 mirror during a resync?
If not- is there a reason why not beyond the extra space overhead and
read compute write overhead?
This issue interests me more as I look into SSDs and having flash blocks
wear out.
I'd choose a higher raid level if i could, but this is only a very small
atom 330 box with only mildly important data. I think I'm ultimately
looking for something like ZFS has, but ZFS under RHEL/CentOS will
probably never happen in any meaningful production worthy way due
licensing and the ultimate demise of sun and tainting of things that is
Oracle.
I'd love any information anyone has on the subject.
-Brett
next reply other threads:[~2010-08-18 3:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-18 3:56 Brett L. Trotter [this message]
2010-08-18 7:45 ` the true behavior of mdadm's raid-1 with regard to vertical parity and silent error detection/scrubbing- confirmation or feature request Michael Tokarev
2010-08-18 8:00 ` Mikael Abrahamsson
2010-09-04 18:38 ` Bill Davidsen
2010-09-04 18:56 ` Mikael Abrahamsson
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=4C6B59F6.5020001@silcon.com \
--to=brett@silcon.com \
--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.