From: Greg Freemyer <greg.freemyer@gmail.com>
To: Bill Davidsen <davidsen@tmr.com>
Cc: John Robinson <john.robinson@anonymous.org.uk>,
Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: If your using large Sata drives in raid 5/6 ....
Date: Fri, 5 Feb 2010 11:14:17 -0500 [thread overview]
Message-ID: <87f94c371002050814v6352826er4f079f436068852@mail.gmail.com> (raw)
In-Reply-To: <4B6C3B7D.2090502@tmr.com>
On Fri, Feb 5, 2010 at 10:38 AM, Bill Davidsen <davidsen@tmr.com> wrote:
<snip>
>>> The good news is that Western Digital is apparently introducing a new
>>> series of drives with an error rate "2 orders of magnitude" better
>>> than the current generation.
>>
>> It's not borne out in their figures; WD quote "less than 1 in 10^15 bits"
>> which is the same as they quote for their older drives.
>>
>> What sums I've done, on the basis of a 1 in 10^15 bit unrecoverable error
>> rate, suggest you've a 1 in 63 chance of getting an uncorrectable error
>> while reading the whole surface of their 2TB disc. Read the whole disc 44
>> times and you've a 50/50 chance of hitting an uncorrectable error.
>>
> Rethink that, virtually all errors happen during write, reading is
> non-destructive, in terms of what's on the drive. So it's valid after write
> or it isn't, but having been written correctly, other than failures in the
> media (including mechanical parts) or electronics, the chances of "going
> bad" are probably vanishingly small. And since "write in the wrong place"
> errors are proportional to actual writes, long term storage of unchanging
> data is better than active drives with lots of change.
Bill,
I thought writes went to the media unverified. Thus if you write data
to a newly bad sector you won't know until some future point when you
try to read it.
During the read is when the bad CRC is detected and the sector marked
for future relocation. The relocation of course does not happen until
another write comes along. Thus the importance of doing a background
scan routinely to detect bad sectors and when encountered to rebuild
the info from other drives and then rewrite it thus triggering the
remapping to a spare sector.
If I've got that wrong, I'd appreciate a correction.
Greg
next prev parent reply other threads:[~2010-02-05 16:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87f94c371002021440o3b30414bk3a7ccf9d2fa9b8af@mail.gmail.com>
2010-02-02 22:46 ` If your using large Sata drives in raid 5/6 Greg Freemyer
2010-02-03 9:27 ` Steven Haigh
2010-02-03 10:56 ` Mikael Abrahamsson
2010-02-03 12:24 ` Goswin von Brederlow
2010-02-03 11:25 ` Goswin von Brederlow
2010-02-03 14:08 ` John Robinson
2010-02-05 15:38 ` Bill Davidsen
2010-02-05 16:14 ` Greg Freemyer [this message]
2010-02-05 17:12 ` Bill Davidsen
2010-02-05 16:59 ` John Robinson
2010-02-05 17:40 ` Bill Davidsen
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=87f94c371002050814v6352826er4f079f436068852@mail.gmail.com \
--to=greg.freemyer@gmail.com \
--cc=davidsen@tmr.com \
--cc=john.robinson@anonymous.org.uk \
--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).