[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <44D219F9.9080404@namesys.com>
Date: Thu, 03 Aug 2006 19:44:57 +0400
From: Edward Shishkin <edward@...esys.com>
To: Matthias Andree <matthias.andree@....de>
CC: Hans Reiser <reiser@...esys.com>, 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
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.
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