All of lore.kernel.org
 help / color / mirror / Atom feed
From: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
To: Gionatan Danti <g.danti@assyoma.it>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, linux-raid@vger.kernel.org
Subject: Re: On URE and RAID rebuild - again!
Date: Tue, 5 Aug 2014 21:01:59 +0200	[thread overview]
Message-ID: <20140805190159.GA2897@lazy.lzy> (raw)
In-Reply-To: <35916d10dab6084e6f28da2e0975fce7@assyoma.it>

On Tue, Aug 05, 2014 at 12:44:04AM +0200, Gionatan Danti wrote:
[...]
> Yes, I understand this. However, the linked article (and many others) state:
> "If you have a 2TB drive, you write 2TB to it, and then you fully read that,
> just over 6 times, then you will run into one read error, theoretically
> speaking."

This means they, who wrote the article, did not
really *tested* what they wrote.
Which already tells us a lot about the quality
of the article itself.

> I read my 500 GB drive over _60_ times, reading 3x more total data than
> stated above.
> 
> I started the entire discussion to know how UREs are calculated, trying to
> understand if they are expressed as probability ("1 probabily over 10^14
> that we can not read a sector) or a statistical record ("we found that 1 on
> 10^14 is not readable").

What's the difference between "probability" and
"statistical record"?
Is not one calculated with the other?

> If defined as a probability, I am very lucky: if my math is OK, I should
> have only 0.5% to read about 40 TB of data (my math is:
> (1-(1/10^14))^(3*(10^14))). If, on the other hand, UREs are defined as

I'm to lazy to try to understand what 3*10^14 is.
What is it?

> statistical evidence (as MTBF), environment and test conditions (eg: duty
> cycle, read/write distribution, etc) are absolutely critical to understand
> what this parameter really mean for us.

I'm under the impression you did not grasp the
concept of probability is such contex.
Given that it is not clear how the manufacturers
compute their numbers, both cases you describe
are the same.
All the possible conditions are included in the
probability computation.

You can state: under worst case scenario, *each*
bit has a probability of 10E-14 of being wrong.
What does this mean?

> I'm under impression (and maybe I'm wrong, as usual :)) that UREs mainly
> depends on incomplete writes and/or unsable sectors. If this is the case,
> maybe the published URE values are related to the entire HDD warranty. In
> other word, they should be read as "in normal condition, with typical loads,
> out HDD will exibit about 1/10^14 unrecoverable error during the entire disk
> lifespan".

As already wrote by others, it is not clear what
that number (10E-14) means.
A common understanding could be, as stated above,
each bit has a *probability* of 10E-14 of being wrong.

Practically, it does *not* mean that reading 10E14 bit
will deliver one bit wrong sistematically.

Furthermore, as already again stated, very likely
an "average" HDD has much lower URE probability.

> 
> It is reasonable? Or I am horribly wrong?

Is this pure curiosity from your side or are
you trying to achieve something?

There is a report, from CERN I think, provinding
real world statistics about HDD problems.

http://storagemojo.com/2007/09/19/cerns-data-corruption-research/

bye,

pg

> Regards.
> 
> -- 
> Danti Gionatan
> Supporto Tecnico
> Assyoma S.r.l. - www.assyoma.it
> email: g.danti@assyoma.it - info@assyoma.it
> GPG public key ID: FF5F32A8
> --
> 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

-- 

piergiorgio

  parent reply	other threads:[~2014-08-05 19:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-30  8:29 On URE and RAID rebuild - again! Gionatan Danti
2014-07-30 11:13 ` Mikael Abrahamsson
2014-07-30 13:05   ` Gionatan Danti
2014-07-30 21:31     ` NeilBrown
2014-07-31  7:16       ` Gionatan Danti
2014-08-02 16:21         ` Gionatan Danti
2014-08-03  3:48           ` NeilBrown
2014-08-04  7:02             ` Mikael Abrahamsson
2014-08-04  7:13               ` NeilBrown
2014-08-04 13:27             ` Gionatan Danti
2014-08-04 18:40               ` Mikael Abrahamsson
2014-08-04 22:44                 ` Gionatan Danti
2014-08-04 23:29                   ` NeilBrown
2014-08-05  6:52                     ` Gionatan Danti
2014-08-05 19:01                   ` Piergiorgio Sartor [this message]
2014-08-05 19:42                     ` Gionatan Danti
2014-08-06 17:05                       ` Chris Murphy
2014-08-06 16:34                   ` Chris Murphy

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=20140805190159.GA2897@lazy.lzy \
    --to=piergiorgio.sartor@nexgo.de \
    --cc=g.danti@assyoma.it \
    --cc=linux-raid@vger.kernel.org \
    --cc=swmike@swm.pp.se \
    /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.