linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).