From: Roger Heflin <rogerheflin@gmail.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: John Robinson <john.robinson@anonymous.org.uk>,
Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: feature suggestion to handle read errors during re-sync of raid5
Date: Sun, 31 Jan 2010 19:30:57 -0600 [thread overview]
Message-ID: <4B662ED1.3060003@gmail.com> (raw)
In-Reply-To: <alpine.DEB.1.10.1001311854530.15329@uplift.swm.pp.se>
Mikael Abrahamsson wrote:
> On Sun, 31 Jan 2010, John Robinson wrote:
>
>> iirc part of the point of moving to 4K sectors is to improve the error
>> correction to something like 1 in 10^20 or 22 without losing storage
>> density, partly by using what was lost before in inter-sector gaps and
>> partly because you can do better with more bits of ECC over more data.
>>
>> Frankly I wish they'd sacrificed a little storage density and improved
>> the error rate a long time ago.
>
> Looking at the data sheet for WD20EADS and WD20EARS they both have 10^15
> "non-recoverable read errors per bits read", so at least in the data
> sheet nothing has really changed in the error rate aspect.
>
Based on my experience, I am not sure how sensible that parameter is
without a time constraint added to it, unless the parameter applies to
the underlying patter, and means it is still correctable and does not
represent a error reported back by the disk to the user.
Bit errors seem more likely the longer a sector has set since being
written. I would be not expect to see errors if you read the entire
disk, and then reread it 1x a day for a year, but if you read the disk
once, let it sit spinning for a year without any reads and read it
again, this will almost certainly get a read error. When you keep
rereading it, when the bits start to go bad the disk should move it
long before data loss happens, but if you only read it 1x a year, it
is likely that when you find the data bad there will be too many bad
bits, beyond being able to correct it.
next prev parent reply other threads:[~2010-02-01 1:30 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-30 12:37 feature suggestion to handle read errors during re-sync of raid5 Mikael Abrahamsson
2010-01-30 17:51 ` Giovanni Tessore
2010-01-30 19:04 ` John Robinson
2010-01-30 21:33 ` Mikael Abrahamsson
2010-01-30 22:04 ` Asdo
2010-01-30 22:25 ` Mikael Abrahamsson
2010-01-31 16:17 ` John Robinson
2010-01-31 16:34 ` Asdo
2010-01-31 18:04 ` Goswin von Brederlow
2010-01-31 17:56 ` Mikael Abrahamsson
2010-02-01 1:30 ` Roger Heflin [this message]
2010-02-01 7:15 ` Mikael Abrahamsson
2010-02-01 13:33 ` Guy Watkins
2010-02-01 13:42 ` Mikael Abrahamsson
2010-02-01 15:15 ` Goswin von Brederlow
2010-02-01 16:28 ` Mikael Abrahamsson
2010-02-01 20:30 ` Richard Scobie
2010-02-02 11:06 ` John Robinson
2010-01-30 21:09 ` Asdo
2010-01-30 18:59 ` Goswin von Brederlow
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=4B662ED1.3060003@gmail.com \
--to=rogerheflin@gmail.com \
--cc=john.robinson@anonymous.org.uk \
--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 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).