From: "H. Peter Anvin" <hpa@zytor.com>
To: Thiemo Nagel <thiemo.nagel@ph.tum.de>
Cc: Linux RAID Mailing List <linux-raid@vger.kernel.org>
Subject: Re: On the subject of RAID-6 corruption recovery
Date: Fri, 04 Jan 2008 16:45:21 -0800 [thread overview]
Message-ID: <477ED321.6000708@zytor.com> (raw)
In-Reply-To: <51481.88.217.65.202.1199493668.squirrel@www.e18.physik.tu-muenchen.de>
Thiemo Nagel wrote:
>>> For errors occurring on the level of hard disk blocks (signature: most
>>> bytes of the block have D errors, all with same z), the probability for
>>> multidisc corruption to go undetected is ((n-1)/256)**512. This might
>>> pose a problem in the limiting case of n=255, however for practical
>>> applications, this probability is negligible as it drops off
>>> exponentially with decreasing n:
>>>
>> That assumes fully random data distribution, which is almost certainly a
>> false assumption.
>
> Agreed. This means, that the formula only serves to specify a lower limit
> to the probability. However, is there an argumentation, why a pathologic
> case would be probable, i.e. why the probability would be likely to
> *vastly* deviate from the theoretical limit? And if there is, would that
> argumentation not apply to other raid 6 operations (like "check") also?
> And would it help to use different Galois field generators at different
> positions in a sector instead of using a uniform generator?
>
What you call "pathologic" cases when it comes to real-world data are
very common. It is not at all unusual to find sectors filled with only
a constant (usually zero, but not always), in which case your **512
becomes **1.
It doesn't mean it's not worthwhile, but don't try to claim it is
anything other than opportunistic.
-hpa
next prev parent reply other threads:[~2008-01-05 0:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-28 2:58 On the subject of RAID-6 corruption recovery H. Peter Anvin
2007-12-28 14:38 ` Bill Davidsen
2007-12-28 17:34 ` H. Peter Anvin
2008-01-04 23:59 ` Thiemo Nagel
2008-01-05 0:03 ` H. Peter Anvin
2008-01-05 0:41 ` Thiemo Nagel
2008-01-05 0:45 ` H. Peter Anvin [this message]
2008-01-05 1:25 ` Thiemo Nagel
2008-01-05 1:49 ` H. Peter Anvin
2008-01-07 9:28 ` Thiemo Nagel
2008-01-07 9:58 ` Mattias Wadenstein
2008-01-07 11:10 ` Thiemo Nagel
2008-01-07 17:20 ` H. Peter Anvin
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=477ED321.6000708@zytor.com \
--to=hpa@zytor.com \
--cc=linux-raid@vger.kernel.org \
--cc=thiemo.nagel@ph.tum.de \
/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).