[linux-l] mbox/Maildir/tar

[Rocco Rutte]

Hi,

* Steffen Dettmer wrote:
>* Rocco Rutte wrote on Thu, Nov 29, 2007 at 09:45 +0100:
>> * Steffen Dettmer wrote:
>> >* Oliver Bandel wrote on Tue, Nov 27, 2007 at 22:22 +0100:

>> >> Eine Fehlerkorrektur wäre vielleicht auch ganz sinnvoll.

>> >Gibt es sowas eigentlich? Was beispielsweise konfigurierbar Redundanz in
>> >Datenströme einfügt oder so?

>> Ja, mit dem Hamming-Code zum Beispiel.

>Ja, und wie heisst es nun? :-)

>Ein Link wäre nett. Die Anwendung, die mir sofort einfällt, ist die der
>Datensicherung z.B. auf DVDs, DATs und andere `unzuverlässige' Medien -
>das ist sicherlich auch schon anderen eingefallen :)

Ach so, ich dachte Fehlerkorrektur war gemeint. Hamming-Code kann man 
dafür benutzen.

>Da müsste man auch ein paar sinnvolle Konfigurationswerte wissen, wenn
>man das in seine pipe einbauen will, also Beispieldaten oder
>Erfahrungswerte für DVD-RAM und andere für DAT etc.

Das kommt drauf an. Bei Hamming kann man ausrechnen wieviel Byte 
zusätzlich man für Redundanz braucht, um X Fehler zu erkennen und zu 
beheben. X hängt aber vom Medium/Kanal ab, d.h. man kann das nicht 
allgemeingültig sagen. Wenn Laufwerkstyp X gut funktioniert gibt es im 
Mittel mal einen Fehler, bei einem anderen aber 5*X oder so.

>Hamming-Code ist meines Verständnisses nach hier übrigens gerade nicht
>geeignet, da ein DVD Laufwerk bei einem Lesefehler meines Wissens nach
>den Datenblock überhaupt nicht zurückgibt, so dass man den/die Bitfehler
>nicht korrigieren kann. Bei Bändern mit "knick" würde ich auch gleich
>viele Bitfehler an einer Stelle erwarten. Machen Hamming-Codes mit sehr
>grossen Abständen (100.000 Bits oder so) Sinn? Hätte eher daran gedacht,
>Datenblöcke in grösseren Abständen nochmal zu schreiben, bisschen
>verteilt, so `ganz grob in Richtung' RAID5 (jajaja hinkt oder Ende ich
>weiss :)).

Das ist auch blöd, weil dir nach Murphy genau die redunndanten Blöcke 
immer paarweise abrauchen. :)

Bei Hamming wird glaube ich (Beispiel) ein Byte mit 5 Bytes Daten und 3 
Bytes parity übertragen, also muss man 2 komplette Byte senden, um 1 
Byte Rohdaten zu schaufeln. Das lässt sich ja alles in Hardware 
effizient implementieren. Wie robust das aber ist, wenn zwischendrin mal 
ein paar Byte/Blöcke fehlen, weiss ich nicht.

MfG, Rocco