From: Maarten <maarten@ultratux.net>
To: linux-raid@vger.kernel.org
Subject: Re: Suboptimal raid6 linear read speed
Date: Sun, 20 Jan 2013 01:49:56 +0100 [thread overview]
Message-ID: <50FB3F34.3000302@ultratux.net> (raw)
In-Reply-To: <6675858F-43FC-48CE-B146-856F50481289@colorremedies.com>
On 01/20/13 01:16, Chris Murphy wrote:
>
> On Jan 19, 2013, at 4:51 PM, Maarten <maarten@ultratux.net> wrote:
>
>> On 01/19/13 23:48, Stan Hoeppner wrote:
>>> On 1/19/2013 1:43 AM, Mikael Abrahamsson wrote:
>>>
>>>> With a BER of 10^-14 you have a 16% risk of getting URE when reading an
>>>> entire 2TB drive.
>>> On 1/19/2013 7:21 AM, Roy Sigurd Karlsbakk wrote:
>>>
>>>> ok, perhaps, maybe, but then it's 17% chance of losing data after a
>>>> mirror or raid-5 rebuild with 2TB drives...
>>> Where are you guys coming up with this 16-17% chance of URE on any
>>> single full read of this 2TB, 10E14 drive? The URE rate here is 1 bit
>>> for every 12.5 trillion bytes. Thus, statistically, one must read this
>>> drive more than 6 times to encounter a URE. Given that, how is any
>>> single full read between the 1st and the 6th going to have a 16-17%
>>> chance of encountering a URE for that one full read? That doesn't make
>>> sense.
>> Sorry but now I have to speak up too. Of course that 16-17% figure is
>> right! Did you miss out on math classes ? It is all statistics. There is
>> a chance of '1.0' to get one URE reading 12.5 TB. That URE may be
>> encountered at the very start of the first TB, or it may not come at
>> all, because that is how statistics work. But *on*average*, you'll get
>> 1.0 URE per 12.5 TB, ergo, 0.16 per 2.0 TB. Basic simple math… jeez.
>
> Please explain this basic, simple math, where a URE is equivalent to 1 bit of information. And also, explain the simple math where bit of error is equal to a URE. And please explain the simple math in the context of a conventional HDD 512 byte sector, which is 4096 bits.
>
> If you have a URE, you have lost not 1 bit. You have lost 4096 bits. A loss of 4096 bits in 12.5TB (not 12.5TiB) is an error rate of 1 bit of error in 2.44^10 bits. That is a gross difference from published error rates.
>
> And then explain how the manufacturer spec does not actually report the URE in anything approaching "on average" terms, but *less than* 1 bit in 10^14. If you propose the manufacturers are incorrectly reporting the error rate, realize you're basically accusing them of a rather massive fraud because less than 1 bit of error in X, is a significantly different thing than "on average" 1 bit of error in X. This could be up to, but not including, a full order magnitude higher error rate than the published spec. It's not an insignificant difference.
All very nice, but that is not the point, is it. The point is, to
calculate (or rather: estimate) the odds of an URE encounter when
reading 2TB, based on the figure one has for reading 12,5 TB. Whether
that 12,5 figure is correct or not, whether endorsed by manufacturers or
not, is totally irrelevant. It simply boils down to, if there are 10
X's in every 10G Y's, then there are 2 X's in every 2G Y's. Yes ?
cheers,
Maarten
>
> Chris Murphy
>
--
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:[~2013-01-20 0:49 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-15 12:33 Suboptimal raid6 linear read speed Peter Rabbitson
2013-01-15 12:45 ` Mikael Abrahamsson
2013-01-15 12:56 ` Peter Rabbitson
2013-01-15 16:13 ` Mikael Abrahamsson
2013-01-15 12:49 ` Phil Turmel
2013-01-15 12:55 ` Peter Rabbitson
2013-01-15 17:09 ` Charles Polisher
2013-01-15 19:57 ` keld
2013-01-16 4:43 ` Charles Polisher
2013-01-16 6:37 ` Tommy Apel Hansen
2013-01-16 9:36 ` keld
2013-01-16 16:09 ` Charles Polisher
2013-01-16 20:40 ` EJ Vincent
2013-01-15 23:17 ` Phil Turmel
2013-01-16 2:48 ` Stan Hoeppner
2013-01-16 2:58 ` Peter Rabbitson
2013-01-16 20:29 ` Stan Hoeppner
2013-01-16 21:20 ` Roy Sigurd Karlsbakk
2013-01-17 15:51 ` Mikael Abrahamsson
2013-01-18 8:31 ` Stan Hoeppner
2013-01-18 9:18 ` Mikael Abrahamsson
2013-01-18 22:56 ` Stan Hoeppner
2013-01-19 7:43 ` Mikael Abrahamsson
2013-01-19 22:48 ` Stan Hoeppner
2013-01-19 23:51 ` Maarten
2013-01-20 0:16 ` Chris Murphy
2013-01-20 0:49 ` Maarten [this message]
2013-01-20 1:37 ` Phil Turmel
2013-01-20 9:44 ` Chris Murphy
2013-01-20 6:26 ` Mikael Abrahamsson
2013-01-20 9:39 ` Chris Murphy
2013-01-20 16:55 ` Mikael Abrahamsson
2013-01-20 17:15 ` Chris Murphy
2013-01-20 17:17 ` Mikael Abrahamsson
2013-01-20 17:20 ` Chris Murphy
2013-01-19 23:53 ` Phil Turmel
2013-01-20 9:04 ` Wolfgang Denk
2013-01-20 19:28 ` Peter Grandi
2013-01-20 21:09 ` Mikael Abrahamsson
2013-01-20 21:50 ` Peter Grandi
2013-01-21 5:24 ` Mikael Abrahamsson
2013-01-21 14:40 ` Peter Rabbitson
2013-01-21 20:32 ` Peter Grandi
2013-01-21 20:55 ` Peter Grandi
2013-01-21 22:00 ` Peter Grandi
2013-01-19 13:21 ` Roy Sigurd Karlsbakk
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=50FB3F34.3000302@ultratux.net \
--to=maarten@ultratux.net \
--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 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).