Re: single disk reed solomon codes

Gerald Nowitzky
2008-07-19T15:18:04Z

ECC codes like Reed-Solomon are very useful to recognize and locate random
bit-errors. On a HDD as a unit, as it is seen from OS level, I don't think
it will be of any help: When a HDD drive reads a sector from disk, it does a
whole bunch of error recognition and correction measures. Usually there are,
at least, two layers of error correction with different bit spreads on it.
*If* this still isn't enough, it is very likely that the whole sector will
come back completely spoiled, or, much more likely, won't come back at all
and the drive will report a read error.

So, the only thing that could be done is to add some redundancy on
sector-level with something like a "Intra-Disk-RAID5" by adding a number of
parity sectors. A simple parity will be enough, as error recognition and
location can be done by sector checksums. However, there will be a *huge*
performance penalty, as every sector write will cause an additional seek and
write for the parity sector.

In the end, you would add very little security by the price of -at least-
cutting half your write performance. Thus, I don't think there is any point
in adding redundancy to single disk systems.

Just my 2 cents...
(Gerald)

>Hi,
>Since btrfs is someday going to be the default FS for Linux, and will
>be on so many single disk PCs and laptops, I was thinking it should be
>a good idea to insert some redundancy in single disk deployments. Of
>course it can help with disk failures, since it's obviously a "single"
>disk, but it can help with bit-rot, and with hardware sector read
>errors. To get that we'd need to implement some kind of forward error
>correction, possibly reed solomon code. I am not sure why no
>filesystem seems to implement such scheme, although I believe at the
>hardware level, such schemes are being used (so the idea is
>applicable) ?
>Not that I am an expert on such matters, but I thought I'd drop that
>suggestion here, maybe at least I'll know why no one else seems to do
>that