linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).