Bandlaufwerke und Kompression (was: Re: Martin's Privatmeinung)

J Wunsch <de-bsd-questions(at)DE.FreeBSD.ORG> wrote:

> Komprimierung der Tapelaufwerke ist aber an deren Hardware-Blockgröße
> gebunden. Leider lassen nur wenige Hersteller so tief in Details
> gucken, daß Du darüber was erfährst. Du kannst aber davon ausgehen,
> daß die größten Hardwareblockgrößen heutiger Tapelaufwerke bei
> einigen wenigen Kilobyte liegen. Komprimiert wird dann innerhalb
> dieser Blöcke, mehr nicht.

Das ergibt keinen Sinn.

Wenn das Laufwerk mit einer festen Blockgröße auf Band schreibt,
dann ist es unsinnig, Eingabebrocken dieser Größe zu komprimieren,
weil das Ergebnis dann ja eben nicht mehr einen Block füllt. Egal,
was für Eingabeeinheiten komprimiert werden, muss ein Reblocking
durchgeführt werden.

Ich kann die Eingabedaten einfach als bis zum Bandende unendlichen
Datenstrom behandeln (mit Markierung der Eingabeblockung). Bei
einem LZ78-Packer läuft mir irgendwann das Wörterbuch voll, und
ich muss mir überlegen, was ich damit mache. Mit dem alten Wörterbuch
weiterarbeiten, in der Hoffnung, dass die folgenden Daten dieselbe
Charakteristik haben wie die vorhergehenden? Das Wörterbuch einfach
zurücksetzen? Erstmal weiterarbeiten, Kompressionsrate prüfen, und
wenn sie fällt das Wörterbuch zurücksetzen? Bei einem zyklisch
adaptiven Packer wie LZ77 stellt sich das Problem nicht.

Ich kann den Kompressor auch für jeden logischen Block zurücksetzen,
wie DLZ1 bei DLT das tut. Wenn ich ihn dann bis zum Blockende auch
mit vollem Wörterbuch laufen lasse, dann ist das für LZ78 eine
bequeme Lösung. Für LZ77 bringt mir das nix, außer dem Nachteil
einer neuen Adaptionsphase mit schlechter Kompression.

Das Wörterbuch für jeden logischen Block zurückzusetzen hat einen
Vorteil. Wenn ein Bandblock nicht mehr lesbar ist, dann werden nur
die logischen Blocks, die zum Teil in ihm liegen, zerstört. Der
Rest ist nicht betroffen. Packe ich einen Endlosdatenstrom, dann
ist alles ab dem Lesefehler verloren.

Wir reden hier von auch von eher kleinen Wörterbüchern. DCLZ hat
maximal 4092 Einträge, ALDC ein Fenster von 0.5/1/2kB. Das liefert
auch für recht kleine einzeln komprimierte Blöcke (z.B. 10kB) gute
Ergebnisse und wir laufen da sehr schnell in ein »law of diminishing
returns« (deutsch?).

Man kann natürlich auch eine dreistufige Blockung einführen...
1. logische Blockgröße, 2. Kompressionsblockgröße, 3. Bandblockgröße.

Kleiner Versuch am Rande: Kompression eines englischen Textes mit
LZW, 2^12 Wörterbucheinträge, und verschiedenen Blockgrößen.

naddy(at)kemoauc[~/tmp/d] ll
total 3504
-rw-r--r-- 1 naddy naddy 1307538 Nov 22 20:46 foo
-rw-r--r-- 1 naddy naddy 735657 Nov 22 21:09 foo.10k.Z
-rw-r--r-- 1 naddy naddy 757048 Nov 22 21:11 foo.64k.Z
-rw-r--r-- 1 naddy naddy 745144 Nov 22 21:08 foo.Z

foo:
    Ausgangsdaten, die Sourcen des FreeBSD-Handbuchs, von den
    ärgsten Wiederholungen (Leerzeichen am Zeilenanfang, SGML-Tags)
    befreit.
foo.10k.Z,
foo.64k.Z:
    Ausgangsdaten in Teile zu 10 bzw 64kB geschnitten, einzeln mit
    »compress -b12« gepackt, und wieder zusammengefügt.
foo.Z:
    »compress -b12 foo«

> Die Limitierung auf derartige Blockgrößen ist für die Anwendung
> einer automatischen Fehlerkorrektur unabdinglich

Ach was, es bietet sich nur an wegen Pufferspeicher und Laufzeit
die Blöcke nicht gar zu groß zu machen.

> wir leben schließlich nicht mehr in einer Zeit wie früher bei
> den Floppies, wo man hinterher alles nochmal kontrollesen mußte...

War da nicht was, dass (bestimmte Typen) Bandlaufwerke das genau
so handhaben? Die geschriebenen Daten gleich wieder lesen und
vergleichen?

-- 
Christian "naddy" Weisgerber                          naddy(at)mips.inka.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message