[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44D231DF.1080804@namesys.com>
Date: Thu, 03 Aug 2006 11:26:55 -0600
From: Hans Reiser <reiser@...esys.com>
To: Edward Shishkin <edward@...esys.com>
CC: Matthias Andree <matthias.andree@....de>, ric@....com,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Adrian Ulrich <reiser4@...nkenlights.ch>,
"Horst H. von Brand" <vonbrand@....utfsm.cl>,
bernd-schubert@....de, reiserfs-list@...esys.com,
jbglaw@...-owl.de, clay.barnes@...il.com, rudy@...ons.demon.nl,
ipso@...ppymail.ca, lkml@...productions.com, jeff@...zik.org,
tytso@....edu, linux-kernel@...r.kernel.org
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org
regarding reiser4 inclusion
Edward Shishkin wrote:
> Matthias Andree wrote:
>
>> On Tue, 01 Aug 2006, Hans Reiser wrote:
>>
>>
>>> You will want to try our compression plugin, it has an ecc for every
>>> 64k....
>>
>>
>>
>> What kind of forward error correction would that be,
>
>
>
> Actually we use checksums, not ECC. If checksum is wrong, then run
> fsck - it will remove the whole disk cluster, that represent 64K of
> data.
How about we switch to ecc, which would help with bit rot not sector loss?
>
>
> and how much and
>
>> what failure patterns can it correct? URL suffices.
>>
>
> Checksum is checked before unsafe decompression (when trying to
> decompress incorrect data can lead to fatal things). It can be
> broken because of many reasons. The main one is tree corruption
> (for example, when disk cluster became incomplete - ECC can not
> help here). Perhaps such checksumming is also useful for other
> things, I didnt classify the patterns..
>
> Edward.
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists