From: Asdo <asdo@shiftmail.org>
To: John Robinson <john.robinson@anonymous.org.uk>
Cc: 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 17:34:23 +0100 [thread overview]
Message-ID: <4B65B10F.6060501@shiftmail.org> (raw)
In-Reply-To: <4B65AD05.5050000@anonymous.org.uk>
John Robinson wrote:
> On 30/01/2010 21:33, Mikael Abrahamsson wrote:
> [...]
>> I think the 4k sector size on WD20EARS (for instance) is supposed to
>> add more ECC information but I'm not sure how this will affect the
>> 10^14 error rate.
>
> 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.
I remember the other way around: the purpose of 4k was to keep the same
error rate while saving storage space
You have links?
I got my impression from here http://lwn.net/Articles/322777/ but it's
not explicitly written
> Frankly I wish they'd sacrificed a little storage density and improved
> the error rate a long time ago.
Me too
Anyway I think you'll never know how many ECC bits a brand uses. It's
not declared. They just declare the estimated error rate which I think
is the estimate of how likely is a surface defect and how likely is that
to be fixable by the ECC algorithm. So the discussion has no real meaning...
There is another maybe more important factor: how likely is silent data
corruption. IIRC reed-solomon algorithms can be tuned (at the same
number of bits) for more correction and less detection of errors, or for
more detection and less correction. If the detection is insufficient,
you get garbage data when reading the sector, but the disk does not
return a read error so the OS takes it as good data. Every 1 bit of
error correction costs the same number of ECC bits as 2 bits of error
detection. The disk makers never tell you how their algorithm is balanced.
next prev parent reply other threads:[~2010-01-31 16:34 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 [this message]
2010-01-31 18:04 ` Goswin von Brederlow
2010-01-31 17:56 ` Mikael Abrahamsson
2010-02-01 1:30 ` Roger Heflin
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=4B65B10F.6060501@shiftmail.org \
--to=asdo@shiftmail.org \
--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).