Messages in this thread | | | Date | Fri, 4 Aug 2006 20:57:46 +0200 | From | "Antonio Vargas" <> | Subject | Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion |
| |
On 8/4/06, Edward Shishkin <edward@namesys.com> wrote: > Hans Reiser wrote: > > 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? > > Interesting aspect. > > Yes, we can implement ECC as a special crypto transform that inflates > data. As I mentioned earlier, it is possible via translation of key > offsets with scale factor > 1. > > Of course, it is better then nothing, but anyway meta-data remains > ecc-unprotected, and, hence, robustness is not increased.. > > Edward. > > > > >> > >> 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. > >> > >>
Would the storage + plugin subsystem support storing >1 copies of the metadata tree?
-- Greetz, Antonio Vargas aka winden of network
http://network.amigascne.org/ windNOenSPAMntw@gmail.com thesameasabove@amigascne.org
Every day, every year you have to work you have to study you have to scene. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |