From: Phil Turmel <philip@turmel.org>
To: Chris Murphy <lists@colorremedies.com>
Cc: "linux-raid@vger.kernel.org List" <linux-raid@vger.kernel.org>
Subject: Re: Questions about bitrot and RAID 5/6
Date: Fri, 24 Jan 2014 14:57:23 -0500 [thread overview]
Message-ID: <52E2C5A3.1050803@turmel.org> (raw)
In-Reply-To: <E222FBA0-8A1A-48EF-BEAA-BD059A8C1554@colorremedies.com>
On 01/24/2014 02:32 PM, Chris Murphy wrote:
>>> So a URE is either 4096 bits nonrecoverable, or 32768 bits
>>> nonrecoverable, for HDDs. Correct?
>>
>> Yes. Note that the specification is for an *event*, not for a
>> specific number of bits lost. The error rate is not "bits lost per
>> bits read", it is "bits lost event per bits read".
>
> I don't understand this. You're saying it's a "1 URE event in 10^14
> bits read" spec? Not a "1 bit nonrecoverable in 10^14 bits read"
> spec?
>
> It seems that a nonrecoverable read error rate of 1 in 2 would mean,
> 1 bit nonrecoverable per 2 bits read. Same as 512 bits nonrecoverable
> per 1024 bits read. Same as 1 sector nonrecoverable per 2 sectors
> read.
I don't know what more to say here. Your "seems" is not.
[trim /]
>> You are confused.
>
> Be specific, because….
>
>> The specification is a maximum of an average.
>
> Stating the average rate is below the max specified rate, is
> consistent with the spec being a maximum of an average. I don't see
> where you're getting the average from when there isn't even an X < Y
> < Z published. All we have is X < Z.
I think you are also struggling with the fact the rate, on a single
drive, aside from any specification, is *itself* an average.
The manufacturer is stating that that average, which cannot be clearly
understood without grasping how a Poisson distribution works (or similar
distributions), won't exceed a certain value within the warranty life (a
maximum). To achieve this, the manufacturer will certainly arrange to
keep the average of these averages below the maximum.
>> An average that changes with time, and cannot be measured from
>> single events.
>
> On that point we agree. But with identical publish error rate specs
> we routinely see model drives give us more problems than others, even
> among the same manufacturer, even sometimes within a model varying by
> batch. So obviously the spec has a rather massive range to it.
To some extent, manufacturers have to make educated guesses about future
performance on new products. They pay real $ penalties in warranty
claims if they err greatly in one direction, and real $ penalties in
"unnecessary" process equipment if the err greatly in the other direction.
Obviously, some manufacturers have better knowledge of their own
production facilities than others.
Um, I think we're drifting off-topic now.
Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-01-24 19:57 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-20 20:34 Questions about bitrot and RAID 5/6 Mason Loring Bliss
2014-01-20 21:46 ` NeilBrown
2014-01-20 22:55 ` Peter Grandi
2014-01-21 9:18 ` David Brown
2014-01-21 17:19 ` Mason Loring Bliss
2014-01-22 10:40 ` David Brown
2014-01-23 0:48 ` Chris Murphy
2014-01-23 8:18 ` David Brown
2014-01-23 17:28 ` Chris Murphy
2014-01-23 18:53 ` Phil Turmel
2014-01-23 21:38 ` Chris Murphy
2014-01-24 13:22 ` Phil Turmel
2014-01-24 16:11 ` Chris Murphy
2014-01-24 17:03 ` Phil Turmel
2014-01-24 17:59 ` Chris Murphy
2014-01-24 18:12 ` Phil Turmel
2014-01-24 19:32 ` Chris Murphy
2014-01-24 19:57 ` Phil Turmel [this message]
2014-01-24 20:54 ` Chris Murphy
2014-01-25 10:23 ` Dag Nygren
2014-01-25 15:48 ` Phil Turmel
2014-01-25 17:44 ` Stan Hoeppner
2014-01-27 3:34 ` Chris Murphy
2014-01-27 7:16 ` Mikael Abrahamsson
2014-01-27 18:20 ` Chris Murphy
2014-01-30 10:22 ` Mikael Abrahamsson
2014-01-30 20:59 ` Chris Murphy
2014-01-27 3:20 ` Chris Murphy
2014-01-25 17:56 ` Wilson Jonathan
2014-01-27 4:07 ` Chris Murphy
2014-01-23 22:06 ` David Brown
2014-01-23 22:02 ` 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=52E2C5A3.1050803@turmel.org \
--to=philip@turmel.org \
--cc=linux-raid@vger.kernel.org \
--cc=lists@colorremedies.com \
/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.