From: Christian Weisgerber (naddy_at_mips.rhein-neckar.de)
Date: 11. Dec 1999
Michael Lestinsky <michael_at_zaphod.rhein-neckar.de> wrote:
> Ist es denn totale Paranoia von mir, wenn ich gerade bei Backups die
> Kompression grundsätzlich ausschalte? Lieber ein Band mehr verwenden,
> als ein gekipptes Bit und damit der ganze komprimierte Mist auf den
> Müll.
Ich bin geneigt, das Bandlaufwerk in dieser Beziehung als Blackbox
zu betrachten. Das sprichwörtliche gekippte Bit gibt es eh nicht
mehr. Die Laufwerke lesen einen Bitvektor mit verwürfelten Nutz-
und Fehlerkorrekturdaten, der einzelnen Bits einen Wert mit einer
gewissen Wahrscheinlichkeit zuordnet, drehen das durch unverständliche
Dekodierer (viel lineare Algebra), und am Ende fallen hoffentlich
die korrekten Daten raus. Letztlich ist das bei Festplatten und
Magnetbändern dieselbe Technik wie bei Digitalfunk.
Die Laufwerkshersteller sollten wissen, wie sie das organisieren
müssen, damit es zuverlässig funktioniert. *Ich* würde das mit
irgendeiner Blockung machen, damit selbst bei harten Lesefehlern
nur ein Teil der Daten ausfällt. Das zu flicken macht natürlich
auch keinen Spass, aber das gilt genauso ohne Kompression. Was die
Laufwerkshersteller konkret implementieren, weiß ich nicht. Ich
glaube einiges davon ist in kostenlos erhältlichen ECMA-Standards
spezifiziert, das kann man bei Interesse nachlesen.
Also: Ich persönlich habe (hätte) keine Bedenken, für Backups die
Kompression des Bandlaufwerks zu benutzen. Was dagegen ausgesprochen
ungeschickt ist, das ist eine Datenstromkompression vor dem Bandlauf-
werk (gzip, bzip2) *ohne* entsprechende Fehlerkorrekturmechanismen.
> Es gibt ftmt, was ein mt für Floppy-Tapes ist. Das konnte mir
> anzeigen, auf welchem Block ich gerade bin, und wieviele noch
> verbleiben. Dazu stand im Haeder des Bandes genau solche Info (wie die
> gesamtzahl der Blöcke auf dem Band) drinn.
Zum Glück ist mir die Arbeit mit Floppystreamern komplett erspart
geblieben, aber da die Bänder formatiert werden mussten, und das
ganze am Floppycontroller hing, nehme ich an, dass analog zur
Diskette eine Softsektorierung stattfand. Dann kann man natürlich
auch in einem Sektor mit Verwaltungsdaten die Blockzahl u.ä.
festhalten.
(Mir wird gerade bewusst, dass die meisten hier Mitlesenden
wahrscheinlich gar nicht wissen, wie Daten auf einer Diskette
gespeichert werden.)
> Wie sieht denn die so ein Band von richtigen Streamern aus? Die haben
> vermutlich kein "Filesystem" drauf, Formatieren kann/muss man
> sie auch nicht, oder?
Richtig.
> Wird Charakter für Character geschrieben oder blockweise?
Letzteres. Grundsätzlich gibt es zwei Modelle: variable und fest
Blockgröße. Je nach Bandsystem wird das eine oder andere oder beides
unterstützt. Ich zitiere der Einfachheit halber die sa(4)-Seite
von FreeBSD:
Variable block-size: Each write made to the device results in
a single logical record written to the tape. One can never read
or write part of a record from tape (though you may request a
larger block and read a smaller record); nor can one read
multiple blocks. Data from a single write is therefore read by
a single read. The block size used may be any value supported
by the device, the SCSI adapter and the system (usually between
1 byte and 64 Kbytes, sometimes more).
Fixed block-size: Data written by the user is passed to the
tape as a succession of fixed size blocks. It may be contiguous
in memory, but it is considered to be a series of independent
blocks. One may never write an amount of data that is not an
exact multiple of the blocksize. One may read and write the
same data as a different set of records, In other words, blocks
that were written together may be read separately, and vice-versa.
Nun muss man sagen, dass bei Bandlaufwerken, wie auch z.B. bei
Festplatten, die interne Arbeitsweise in den letzten >10 Jahren
erhebliche Fortschritte gemacht hat. Variable/feste Blockgröße ist
mehr eine Frage der logischen Schnittstellen als vom dem, was heute
tatsächlich auf Band landet.
Neben irgendwie gearteten Datenblöcken gibt es nur eine weitere
Struktur: die Dateimarke (file mark). Sie zeigt das Ende einer
»Datei« (einer Blockfolge) an. Was auch immer dazu auf Band
geschrieben wird, es ist etwas, das nicht mit einem Block oder
dessen Inhalt verwechselt werden kann. Aus Unix-Sicht wird eine
Dateimarke bei einem close(2) auf das Device geschrieben und liefert
EOF bei read(2). Manche Bandsysteme verwenden eine doppelte Dateimarke
um das Ende des beschriebenen Bands zu kennzeichnen - oder geben
das zumindest bei der Ansteuerung vor.
-- Christian "naddy" Weisgerber naddy_at_mips.rhein-neckar.de
Dieses Archiv wurde generiert von hypermail 2.1.2 : 11. Mar 2002 CET