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

Martin Cracauer <cracauer(at)cons.org> wrote:

> > Leider wieder falsch. Da Kompression ein statistisches Verfahren ist,
> > erreicht man in groesseren Dateien (=Bloecke) bessere Kompressions-
> > raten.
>
> Selbstverstaendlich. Nur leider arbeitet die Kompression des Tapes
> nicht auf den Bloecken, die vom Kernel/Applikation kommen. Also nicht
> "=Bloecke".

Hmm. Eigentlich wollte ich Martin beipflichten, aber ich habe dann
doch etwas recherchiert.

Zuerst gilt es herauszufinden, was für Kompressionsverfahren Band-
laufwerke überhaupt verwenden. mt(1) kennt namentlich »IDRC« und
»DCLZ«. Das alleinige zur Auswahl stehende Verfahren meines DLT4000
wird übrigens als IDRC identifiziert, mehr dazu weiter unten.

· DCLZ
  ECMA-151 <URL:http://www.ecma.ch/ecma1/STAND/ECMA-151.HTM>
  QIC-130 <URL:http://www.qic.org/html/standards/13x.x/qic130c.pdf>

  Das ist ein ganz normaler LZW-Packer (LZ78), wie man ihn von
  compress(1), GIF, oder V.42bis her kennt. Interessant ist, dass
  er ein Codewort für ein Datensatzende (End of Record) beinhaltet,
  d.h. eine eventuelle ursprüngliche Blockung des Eingabedatenstroms
  kann erfasst und bei der Dekompression wieder hergestellt werden.

  Davon, dass das Wörterbuch nach einem Block zurückgesetzt würde,
  kann ich nichts finden. Im Gegenteil das Vorhandensein des
  EOR-Codeworts impliziert, dass es zumindest als Möglichkeit
  vorgesehen ist, unabhängig von der Blockung zu komprimieren.

· ALDC
  ECMA-222 <URL:http://www.ecma.ch/ecma1/STAND/ECMA-222.HTM>
  QIC-154 <URL:http://www.qic.org/html/standards/15x.x/qic154a.pdf>

  Beim Stöbern auf den ECMA- und QIC-Seiten bin ich auf ein weiteres
  Kompressionsverfahren namens ALDC gestoßen. Das ist ein LZ77-Packer,
  wie er z.B. als erste Stufe in gzip(1) verwendet wird. Interessanter-
  weise gibt es dort kein EOR.

· Binary Arithmetic Coding Algorithm
  ECMA-159 <URL:http://www.ecma.ch/ecma1/STAND/ECMA-159.HTM>

  Wie der abkürzunglose Name sagt, handelt es sich dabei um einen
  arithmetischen Packer, offenbar auf die Implementierung in Hardware
  ausgelegt. Er teilt einen logischen Eingabedatensatz (Logical
  Data Record) in 512-Byte-Blöcke auf, die einzeln komprimiert
  werden. Das Ende des LDR wird in der Ausgabe markiert.

Eine Suche nach »IDRC« hat nichts zu Tage gefördert, außer einem
einzigen, dafür aber umso interessanteren Dokument:

    David C. Cressman
    Analysis of Data Compression in the DLT2000 Tape Drive
    Digital Technical Journal, Volume 6, Number 2
    http://www.digital.com/DTJE05/DTJE05SC.TXT

Die DEC-Ingenieure haben Prototypen des DLT2000 mit den Kompressions-
verfahren IDRC und DLZ1 ausgestattet und die Ergebnisse verglichen.
Die Beschreibung von IDRC sieht mir ganz nach ECMA-159 aus. DLZ1
ist wieder eine LZW-Variante, wobei _das Wörterbuch für jeden
logischen Block zurückgesetzt wird_. In dem Zusammenhang interessant
ist die Aussage, dass die maximale Kompressionsrate bei Blöcken
von ungefähr 12kB läge und größere Blöcke gute, aber abnehmende
Effizienz zeigen würden.

Klarer Gewinner des Vergleichs war DLZ1, das dann auch im endgültigen
und für zukünftige Produkte verwendet wurde. Soll heißen, DLT-Laufwerke
verwenden DLZ1-Kompression, wobei jeder logische Block einzeln
gepackt wird.

Schlussfolgerungen:
1. Norbert hat zumindest für DLT prinzipiell recht.
2. Mein DLT4000 lügt mich über sein Kompressionsverfahren an. :-)

-- 
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