[gelöst] backup auf DDS-Tape:compression - ich blick's nicht

Opensuse 11.1, AMD64, 8GB, 2 Stk. DDS3-Tape-Drives (Sony SDT-9000 und ein HP CS1537A)

Ich mache die ersten Versuche mit Bacula und war erstaunt, das bei ziemlich genau 12GB ein DDS3-Tape voll ist.
mt -f /dev/nst0 datcompression zeigt bei beiden Laufwerken "Compression on", also müßte da wenigstens 20% mehr drauf passen (die Dateien waren der normale Windows-Datei Mix; ein tar-gz dampft das im Schnitt um 50% ein).

Jetzt habe ich da mal einen Versuch auf dem Sony gefahren (allerdings mit einem DDS-2 Tape, damit das nicht Ewigkeiten dauert=4GB native). Ich habe dazu zwei 512MB Dateien erstellt. Eine aus /dev/null gefüllt und eine aus /dev/urandom.
Die Sicherung auf Tape nimmt bei beiden ca. 2min40s in Anspruch.
Wenn Kompression wirklich läuft, müsste das wesentlich schneller gehen (bei 10MB/s. SCSI müßte das in unter 1 Min. zum Tape geschickt sein).
Der Blockzähler des Tapes bei 512Byte Blockgräße steigt bei beiden exakt um 1048580 (mt -f /dev/nst0 tell). Somit sind 512MB auf dem Tape.
Wie wird der Blockzähler bestimmt? Wird das NACH der Kompression oder davor gezählt?
Jedenfalls bin ich gerade dabei das Band mit 512MB Null-Files zu füllen. Mal sehen wieviele dieser Pakete drauf passen.

Testweise habe ich mal mittels gzipped-tar die Sicherung ausgeführt (also Compression auf dem Server) und das brachte gerade mal 20 Blocks auf Tape!

Habe ich sonst noch irgend etwas zu beachten, damit die Kompression wirklich im Laufwerk aktiv ist?

Ich habe noch mal cp bigfilezero /dev/null durchgeführt und das brauchte gerade mal 0,3Sekunden zum Lesen. Egal, ob diese Testdaten jetzt aus dem Server-Cache kommen oder irgendwie Sparse-File bedingt sind, jedenfalls ist die Leserate des Filesystems bzw. der Festplatte hier nicht bestimmend.

Also habe ich jetzt noch mal das Bootlog geprüft:
Also das Interface sollte knapp 10MB/s zum Tape transportieren, rechnerisch sind das aber nur knapp 3,5MB/s. Gibt es irgend einen SCSI Speed-Test zu einem einzelnen Device?
Obwohl: Laut http://www.dat-mgm.com/DAT roadmap/ hat DDS-2 eine Transferrate von <729KB/s. Demnach müßte das Backup der 512MB ca. 12Min. dauern. Das kann irgendwie gar nicht stimmen. Wieso sind dann die 512MB Zufallsdaten auch in ca. 3min. auf Tape? Das könnte sein, wenn das DDS-3 Laufwerk die DDS-2 Tapes schneller verarbeitet.


In den man pages von amtapetype steht:

If the device cannot reliably report its comprssion status (and as of this writing, no devices can do so), hardware compression is detected by measuring the writing speed difference of the tape drive when writing an amount of compressable and uncompresseable data. If your tape drive has very large buffers or is very fast, the program could fail to detect hardware compression status reliably.

Zum Vergrößern anklicken....

Also kann man sich auf die Status-Ausgabe von mt wegen des compression-Status nicht verlassen?
Und ich kann hier keinen Unterschied der Schreibrate feststellen, also ist die Kompression wohl doch aus? Bleibt wohl nur die Tapes ausbauen und die DIP-Switches noch mal prüfen (aber ich bin mir sicher, das der Kompression-Schalter aktiviert war).

Bin immer noch dabei die 512MB Files per tar auf das Tape zu schreiben ...

Ich habe eben nach etlichen Zero-Dateien jetzt mal wieder die Random-Datei geschrieben und dieses Mal brauchte das Laufwerk 9min6s. Das ist dann ziemlich dicht an den genannten 720kb/s für DDS-2.
Habe ich bei der ersten Messung der Random-Datei vielleicht geschlampt?
Ich schreibe jetzt mal weiter abwechselnd Random und Zero-Datei.

Hmmmm.... wenn die Kompression doch aktiv ist, und das Laufwerk nur max. 3,5MB/s vom SCSI-Bus abnimmt (weil das Tape normalerweise eh nicht mehr als 720kb/s schreiben kann), dann wären die Werte zu erklären. Laut obiger Grafik vom DDS-Konsortium kann ein DDS-3 <=1,5MB/s auf Tape schreiben. Wenn das SCSI Interface also 3,5MB/s abnimmt reicht das bei einer Kompression von 2:1 durchaus aus das Tape auszulasten. Wenn allerdings SEHR STARK komprimierbare Daten kommen, ist die Transferrate der bremsende Faktor; so wie bei meiner 0-Datei.
Außerdem ist mein DDS2 Tape immer noch nicht voll, obwohl ich schon 16* 512MB = 8GB drauf geschrieben habe (gemischt Zero und Random-Datei).
Also hat sich die Fragestellung der Kompression zum Tape eigentlich erledigt.

So, eben ist der nächste Random-Block auf dem Tape gelandet. Wieder in 9min4s. Also war meine erste Messung von Random und Null irgendwie falsch oder schlampig.
Und dann wäre auch geklärt wie die Blöcke gezählt werden: Vor der Kompression, weil die immer um 2^20 hochgezählt werden; egal ob Random oder Null-Datei!

Eben wieder eine Nulldatei gesichert. die braucht weiterhin nur 2m38s.

Dann spräche einiges dafür, das das ganze Problem in Bacula liegt, und DER die Kompression nicht aktiviert. Bacula setzt ja auch die Blockgröße auf 64512Bytes etc. Vielleicht habe ich da einen Parameter in der Storage-Definition nicht richtig gesetzt.



So,
ich denke dieser Laber-Thread von mir (ich warte halt immer auf die Beendigung jeder Dateisicherung), kann damit als gelöst geschlossen werden.

Zum Abschluß:
Ich breche meine Sicherungsversuche mit dem DDS-2 jetzt mal ab. Ich habe jetzt schon 26*512MB drauf gesichert (gemischt; meist Zero-Files und ein paar Random-Files) = 13,3GB; und das DDS-2 Tape kann native nur 4GB speichern. Also muß die Kompression wohl funktionieren.
Sicherheitshalber muss ich morgen auf der Arbeit (ich habe alle Versuche remote durchgeführt) noch mal das Tape prüfen; nicht das vielleicht doch ein DDS-3 Tape eingelegt ist

Und Ende ...