Bandlaufwerke und LINUX

Achtung dieser Artikel ist noch in Arbeit und dient vorläufig nur als Vorlage. Dieser Beitrag zu Linux oder der Abschnitt ist in Bearbeitung. Weitere Informationen findest du hier. Der Ersteller arbeitet an dem Beitrag oder Abschnitt und entsorgt den Wartungsbaustein spätestens 3 Tage nach der letzten Bearbeitung. Änderungen außer Rechtschreibkorrekturen ohne Absprache mit dem Urspungsautor sind möglichst zu vermeiden, solange dieser Baustein noch innerhalb der genannten Frist aktiviert ist.

Wird was Größeres und wird wohl ein paar Tage länger brauchen bis zur Vollendung --Robi 18:51, 12. Nov 2006 (CET)

Bandlaufwerke bieten die Möglichkeit größere Datenmengen zu Sichern. Tägliche Backups von mehreren Rechnern und täglich einigen hundert GigaByte oder gar TerraByte Größe, die dann auch einige Tage aufbewahrt werden müssen, sind mit anderen derzeit verfügbaren Medien wie zB. DVD oder externe Festplatten nicht mehr handelbar. Besonders die modernen Bandlaufwerke die enorme Sicherungsgeschwindigkeiten und Bandkapazitäten erlauben, stellen jedoch an das Backupkonzept einige Anforderungen, die LINUX per default so nicht berücksichtigt. Speziell für den Einsatz solcher modernen Laufwerke in kleinen Netzwerken oder in kleineren Büroumgebungen unter LINUX werden hier einige spezielle Hinweise gegeben.

Backup mit Bandlaufwerken

Bandlaufwerke eine Übersicht

Was ist ein Streamer und wie funktioniert er

Streamer ist eine andere Bezeichnung für Magnetband-Laufwerk. Der Ausdruck Streamer entstammt dem englischen Begriff "stream". Gemeint ist damit der kontinuierliche Daten-Strom, der sequentiell auf ein Magnetband gespeichert wird. Während also zum Beispiel eine Festplatte im Normalfall im Blockmodus betrieben wird, (es werden also größere Datenblöcke abgelegt und deren genaue Position im Filesystem vermerkt, damit die Blöcke auch wahlfrei wieder gelesen werden können) wird ein Streamer immer von Anfang an sequentiell von vorne nach hinten beschrieben, und die Daten müssen auch wieder so ausgelesen werden. Ein Bandlaufwerk kann man sich vorstellen wie ein Tonband mit 2 Spulen und einem Schreiblesekopf. Die Speicherung erfolgt jedoch nicht wie auf einem herkömmlichen Tonband mit analogen Methoden, sondern auf einen Streamer wird prinzipiel digitale Signale gesichert. Dabei haben sich Laufwerke mit wechselbaren Medien in Form von Kasetten ( Cartridges ) durchgesetzt, ähnlich zB. dem Kassetten eine Kassettensplayers oder zB von VHS-Videorecorder. Dabei ist ein wahlfreier Zugriff, wie wir es zB. von einer Festplatte gewohnt sich, so nicht möglich.

Auf einen Streamer werden in aller Regel keine einzelnen Dateien geschrieben, sondern die Dateien werden mit einem Archiver zB tar oder cpio in Archive gepackt. Der Streamer schreibt beim Sichernzwischen solche Archive spezielle Markierungen (EOF End Of File) und kann so Anfang und Ende solcher Archive erkennen und auch dorthin positionieren. Auf eine bestimmte Datei innerhalb eines Archives kann so aber nicht direkt positioniert werden, da der Streamer und die Backupsoftware die Position der Datenblöcke der einzelnen Dateien innerhalb eines solchen Archives nicht kennt. Das Archiv muss also vom Anfang gelesen werden, bis die gewünschte Datei im Archiv gefunden wird. Da beim Positionieren wirklich eine mechanische Positionierung, sprich ein Umspulen des Bandmateriales dauert eine Positinierung auch einige Sekunden bis Minuten, je nach Laufwerkstype und Technologie. Moderne höhere Backupsoftware packt die Archive aus Frames zusammen, wobei sich in den Headern der einzelnen Frames noch Zusatzinformationen über das Archiv und die darin befindlichen Dateien befinden und/oder legt im Rechner noch zusätzliche Indexdateien an, mit deren Hilfe es möglich wird, auch innerhalb eines Archives in die nähe einer bestimmten Datei zu positionieren. Damit kann uU. einiges an Zeit für das Auslesen einzelner Dateien von einem Band gespart werden.

Was jedoch auf einem Tonband geht, dass man an irgend einer Stelle einfach neu aufnehmen kann, und damit einen Teil der alten Daten dort einfach überschreiben kann, das geht mit Streamern nicht. Wenn irgendwo auf einem Band geschrieben wird, dann sind automatisch alle sich physikalisch dahinter befindliche alten Daten ungültig und nicht mehr zu lesen. Der Versuch dort hin zu positionieren wird mit einer Fehlermeldung abgewiesen. Auch muss immer zwingend am letztem Datenende oder am Ende eines Archives weitergeschrieben werden, und wenn das Beschreiben des Bandes beendet oder abgebrochen wird, an dieser Stelle immer ein EOF (End of File) und ein EOD (End of Data) markiert werden. Nur so wird es möglich das das Laufwerk diese Position auch wiederfinden kann, um zB dort wieder weiterzuschreiben.

Anschlusskonzepte von Bandlaufwerken

Da der Hauteinsatz dieser Laufwerke in der Vergangenheit immer Rechenzentren umfasste, und das bevorzugte Anschlusskonzept dort SCSI ist und war, werden auch heute noch die meisten Streamer mit SCSI angesteuert, oder in der neusten Variante SCSI über Fibre Channel . Daneben gibt es auch einige Geräte die über USB, IDE, SATA usw. angeschlossen werden können, das ist aber ehr die Ausnahme. Die meisten über SCSI angeschlossenen Geräte werden von LINUX problemlos unterstützt. Bei anderen Anschlusskonzepten kann es zu Treiberproblemen kommen.

Aufnahmetechnologie und Bandmaterial

Es gibt eine ganze Reihe von Technologien, die ihrerseits von der Aufnahmetechnologie und der Bandbreite unterschiedlich sind und untereinander nicht kompatibel. Es gibt zB Technologien mit 4mm breiten Bändern, mit 8mm breiten Bändern mit 1/4 Zoll und 1/2 Zoll breiten Bändern. Zwischen dem Bandmaterial und den eigentlichen Schreibleseköpfen muss eine hohe Geschwindigeit erzeugt werden, um die Menge der Daten auch verarbeiten zu können. Dazu wurden verschieden Methoden entwickelt.

Beim Schrägspurverfahren, wie wir es auch von einem Videorecorder her kennen, sind mehrere Schreib-Leseköpfe auf einer sich ständig schnell drehenden Kopftrommel angeordnet. Die Achse der Trommel ist schräg gegen die Bandlaufrichtung geneigt, und das Band wird langsam um die sich drehende Kopftrommel geführt. Dadurch werden die Daten in Streifen schräg auf die gesammte Bandbreite geschrieben.

Beim Längsspurverfahren werden von einem feststehendn Kopf gleichzeitig mehrere Spuren paralell und längs der Bandrichtung geschrieben. Hier wird das Bandmaterial mit einer hohen Geschwindigkeit am Kopf vorbeigeführt. Das Band wird aber nicht über die gesammte Breite mit einem mal beschrieben, sondern in Serpentienen vor und zurück beschrieben, wobei der Kopf in der Hohe verstellt wird, so dass eine Vielzahl einzelner Spuren über die gesammte Bandlänge geschrieben werden.

Selbst bei den einzelnen Herstellern und der einzelnen Technologie gibt es ständig Verbesserungen der Datendichte auf den Bändern, was wiederum neue Standards und andere Aufzeichnungsverfahren und neue Bandtypen nach sich ziehen. Neue Laufwerkstypen unterstützen oftmals einen Teil von früherer Aufzeichnigsstandards, manchmal jedoch nur lesend.

Beispiele für Hersteller und Technologien

• QIC - Abkürzung für "Quarter-Inch-Cartridge", QIC spezifiziert einen Standard für (Streamer)-Kassetten mit 1/4 Zoll breiten Bändern.

• Travan - eine Untergruppe des QIC-Standards und ein Name, der von der Firma 3M (heute/ehemals Imation) ins Leben gerufen wurde. Die Cartridges sind etwas größer als Mini Cartridges und können aufgrund der längeren Bänder mehr Daten speichern.

• LTO - Abkürzung für "Linear Tape-Open Technology" Diesen Standard für Streamer / Bandlaufwerke haben IBM, Hewlett-Packard und Seagate Anfang 1998 vorgestellt.

Moderne heutige Technologien LTO Ultrium 3 ermöglichen Nettokapazitäten von mehr als 160GB und Schreibgeschwindigkeiten von mehr als 70MB/s. Ein Ende der Entwicklung immer schnellerer Laufwerke mit immer größerer Kapazität ist derzeitig nicht abzusehen.

Zwei Entwicklungrichtungen

• "Ultrium" war optimiert auf hohe Kapazität,
• "Accelis" für schnellen Zugriff auf gespeicherte Daten.

• DLT - Abkürzung für "Digital Linear Tape" Bandspeichertechnologie mit linearer Aufzeichnung, die sich lange Zeit als de facto Standard im Midrange und High-End PC Server Markt gehalten hat. Verwendung fand ein 1/2-Zoll breites Magnetband.

• DDS - Abkürzung für "Digital Data Storage" Datensicherungs- System mit DAT-Technologie und folgenden Spezifikationen:

mit Übertragungsgeschwindigkeit und Mediumkapazität ohne Kompression

• DDS-1 -183-366 Kb/s 1.3 bis 2.0 GB
• DDS-2 -500-600 Kb/s 2 - 4 GB
• DDS-3 -bis zu 1 Mb in der Sekunde ;bis 12 GB
• DDS-4 -bis zu 4 Mb in der Sekunde ;20 GB (kompatibel zu den anderen DDS Standards)

• AIT - Abkürzung für "Advanced Intelligent Tape" Sony-Weiterentwicklung der 8mm-Helical Scan-Technologie zur Datenaufzeichnung mit dem besonderen Merkmal, dass sich das Inhaltsverzeichnis auf einem Chip als Bestandteil der Cartridge befindet.

Die Entwicklung geht in einem rasendem Tempo vonstatten. Siehe am Beispiel die LTO Ultrium Technologie, bei der sich mehrere Hersteller auf einen gemeinsamen Standard geeinigt haben, mit dem Ziel mehrere Generationen von solchen Laufwerken zu entwickeln bis zu 6.4TB Kapazität pro Bandkassette und mit Geschwindigkeiten bis 540MB/s. Da solche Geräte heute in großen Stückzahlen produziert werden, und auch das Preis-Leistungsverhältins ständig sinkt, wird es auch für immer kleinere Anwender intressant, mit solchen Geräten zu arbeiten. (siehe auch www.lto-technology.com und http://www.usedlto.com/lto-com-toc.0.html).

Unterstütüzung von Bandlaufwerke unter LINUX

Treiber und Programme

SCSI-Bandlaufwerke werden per default von Linux unterstützt. Der Treiber der dazu genutzt wird ist der st-Treiber, das Programm zur Ansteuerung der verschiedenen Tape-Operationen ist mt. Weitere Laufwerksinterne Operationen und Unterstützung auf SCSI-Ebene kann mit dem optionalem Paketen scsi und xscsi erfolgen. Eine Erweiterung des mt-Befehles und wesentlich bessere Unterstützung für viele Bandlaufwerke und einen besseren Funktionsumfang hat der Befehl mtst aus dem optionalen Paket mt_st. Da die Ansteuerung ausschließlich über den default SCSI-Befehlssatz für Sequentielle Devices des SCSI-Standards beruht, gibt es für die wesentlichen Befehle auch kaum Probleme bei der Unterstützung von einzelnen Laufwerkstypen, und auch die modernsten Laufwerke funktionieren in der Regel uneingeschränkt.

Viele Programme können direkt auf das Bandlaufwerk zugreifen, darunter

• tar,
• cpio,
• dd
• sowie optionale Backuptools und Backupsoftware soweit sie Bandlaufwerken unterstützen.

Leider sind die default Einstellung von LINUX und von vielen Backupprogrammen nicht auf der Höhe der heutigen Laufwerkstechnologien, sondern beruhen noch auf den verfügbaren Bandtechnologien der 80er und 90er Jahre. Um die modernen Laufwerkstypen einigermaßen im Rahmen der Parameter zu betreiben, für die sie gebaut wurden, sind einige Einstellungen zu beachten, da sonst sowohl die Backup- wie auch die Restoregeschwindigkeit so quälend langsam sind, dass damit nicht nur das Backup zur Geduldsache wird, sondern auch Bandmaterial und Laufwerk unter einem stark erhöhtem Verschleiß und mit erhöhtem Fehlerrisiko betrieben wird.

Der richtige Controller

Meistens haben wir es bei Laufwerken mit SCSI SE (Single Ended) oder SCSI LVD (Low Voltage Differential) zu tun, (man sollte aber bedenken, es gibt durchaus auch Laufwerke mit SCSI HVD (alte Bezeichnung: SCSI DIFF) Anschluss, für diese wird ein anderer Controller oder ein SCSI-Adapter benötigt, da die einzelnen Spannungspotentiale am SCSI-Bus hier andere Werte einnehmen, ist bei dem Versuch eines Mischbetriebs von HVD und LVD oder SE am gleichen Bus durchaus auch einmal mit Hardwareschrott als Ergebniss zu rechnen ). Auf die Spezifikationen der Technologie und die daraus resultierenden Anforderungen und Ansprüche an Kabel, Kabellängen und Terminatoren, sowie die Einstellung von SCSI-IDs soll hier nicht näher eingegangen werden. Die älteren Bandlaufwerke arbeiten mit Schreib-Lesegeschwindigkeiten bis 5MB/s oder unwesentlich schneller. Schon hier sollte man aber bedenken für anständige Performance der Bandlaufwerke möglichst nur PCI-Controller verwenden, und möglichst nur ein bis maximal 3 gleichartige Laufwerke am selben SCSI-Bus. Für viele ältere Laufwerke reicht zB ein Adaptec AHA-2940U oder AHA-2940UW vollkommen aus. Moderne Bandlaufwerke arbeiten mit Datenraten von 15-72MB/s und noch schneller. Für diese Laufwerke reicht ein solcher Controller bei Weitem nicht mehr aus, um den Datenhunger des Laufwerkes zu stillen. Für solche Laufwerke wird dann ein "Wide Ultra2, Fast-40 Wide" , "Ultra3, Ultra160, Fast-80" oder "Ultra320, Fast-160" Controller benötigt. Diese Controller sind für die 32Bit PCI-Systeme eines normalen PCs zwar nicht alltäglich, eventuell jedoch trotzdem erhältlich, aber hier können durchaus bei Vollauslastung Engpässe innerhalb des 32 Bit PCI-Bus des Systems auftreten, besonders wenn gleichzeitig auch noch andere PCI-Kontroller unter Last arbeiten. Für eine wirklich Performanten Anschluss von modernen SCSI-Bandlaufwerken zB für den Neuaufbau eines Backupservers, sollte man also von vorne herein gleich Serverhardware mit einem 64Bit PCI-Bus klar bevorzugen. Bei Benutzung eines heute durchaus üblichen Doppelcontrollers in dieser Leistungsklasse und im System eventuell vorhandenen 66MHZ PCI-Bus-Slot, dann ist auch überlegenswert, diesen hierfür zu nutzen. Ein heute vielfach verkauftes LTO3 Laufwerk zB. wird man jedenfalls nicht mehr performant über normale PC-Hardware ansteuern können.

Die richtigen Einstellungen

Das richtige Aufzeichnungsformat

Viele Laufwerke unterstützen neben ihrem ureigenen Aufzeichnungsverfahren der default benutzt wird, auch einige Aufzeichnungsverfahren ihrer Vorgängermodelle. Das schließt Spezifikationen des Aufzeichnungsformates und der verwendetet Bandtypen ein. Die Laufwerke sind so eingestellt, dass sie beim Beschreiben eines Bandes vom Bandanfang immer ihr eigenes default Format wählen, oder wenn das nicht möglich ist, das "höchste Format" dass sowohl das Laufwerk als auch die verwendete Cartridge unterstützt. Wird das Band weiterbeschrieben, wird in dem Format weitergeschrieben, dass am Bandanfang benutzt wurde. Beim Lesen erkennt das Laufwerk das Format mit dem das Band beschrieben ist automatisch. Das verwendete Format wird also beim Lesen des Bandanfanges erkannt und beim Beschreiben am Bandanfang festgelegt. Hier braucht nur selten etwas geändert zu werden.

In Ausnahmefällen, wenn zB mit einem neuerem Laufwerk Daten geschrieben werden, die dann auch mit einem älterem Laufwerk gelesen werden sollen, kann es dennoch notwendig werden. Dann muss beim Beschreiben mit dem neuem Laufwerk dieses anzuweisen werden, das Format zu benutzen, dass dem des altem Laufwerkes entspricht. Das Aufzeichnungsformat ist ein vom Hersteller definierter Hexadezimaler Wert ( density Code ), der dem Laufwerk mitgeteilt werden muss. Der Befehl mstst kennt eine ganze Reihe gebräuchlicher density code, aber längst nicht alle.

root@LINUX:/ # mtst densities
Some SCSI tape density codes:
code   explanation                   code   explanation
0x00   default                       0x20   QIC-6GB
0x01   NRZI (800 bpi)                0x21   QIC-20GB
0x02   PE (1600 bpi)                 0x22   QIC-2GB
0x03   GCR (6250 bpi)                0x23   QIC-875
0x04   QIC-11                        0x24   DDS-2
0x05   QIC-45/60 (GCR, 8000 bpi)     0x25   DDS-3
0x06   PE (3200 bpi)                 0x26   DDS-4 or QIC-4GB
0x07   IMFM (6400 bpi)               0x27   Exabyte Mammoth
0x08   GCR (8000 bpi)                0x28   Exabyte Mammoth-2
0x09   GCR (37871 bpi)               0x29   QIC-3080MC
0x0a   MFM (6667 bpi)                0x30   AIT-1 or MLR3
0x0b   PE (1600 bpi)                 0x31   AIT-2
0x0c   GCR (12960 bpi)               0x33   SLR6
0x0d   GCR (25380 bpi)               0x34   SLR100
0x0f   QIC-120 (GCR 10000 bpi)       0x40   DLT1 40 GB, or Ultrium
0x10   QIC-150/250 (GCR 10000 bpi)   0x41   DLT 40GB
0x11   QIC-320/525 (GCR 16000 bpi)   0x45   QIC-3095-MC (TR-4)
0x12   QIC-1350 (RLL 51667 bpi)      0x47   TR-5
0x13   DDS (61000 bpi)               0x80   DLT 15GB uncomp. or Ecrix
0x14   EXB-8200 (RLL 43245 bpi)      0x81   DLT 15GB compressed
0x15   EXB-8500 or QIC-1000          0x82   DLT 20GB uncompressed
0x16   MFM 10000 bpi                 0x83   DLT 20GB compressed
0x17   MFM 42500 bpi                 0x84   DLT 35GB uncompressed
0x18   TZ86                          0x85   DLT 35GB compressed
0x19   DLT 10GB                      0x86   DLT1 40 GB uncompressed
0x1a   DLT 20GB                      0x87   DLT1 40 GB compressed
0x1b   DLT 35GB                      0x88   DLT 40GB uncompressed
0x1c   QIC-385M                      0x89   DLT 40GB compressed
0x1d   QIC-410M                      0x8c   EXB-8505 compressed
0x1e   QIC-1000C                     0x90   EXB-8205 compressed
0x1f   QIC-2100C                   

Das setzten erfolgt vor dem Beschreiben der ersten Daten am Bandanfang.

root@LINUX:/ # mtst -f /dev/nst0 rewind
root@LINUX:/ # mtst -f /dev/nst0 setdensity 0x27

Falsche Werte oder Werte die das Laufwerk oder die Cartridge nicht unterstützen werden mit einem Fehler abgewiesen. Das Überprüfen des Formates mit dem auf eine Cartridge geschrieben wurde, kann man aus der Statusausgabe herauslesen.

root@LINUX:/ # mtst -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 1024 bytes. Density code 0x27 (Exabyte Mammoth).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

Kompression

Die modernen Streamer und Technologien ermöglichen Datenkomprimierung im Bandlaufwerk selbst. Diese Komprimierung darf man getrost als Hardwarekomprimierung bezeichnen. Diese Komprimierung ist äußerst effizient und Hardware dazu so ausgelegt, dass sie auch die Daten in enormen Geschwindigkeiten verarbeiten kann. Innerhalb der Verarbeitung und Komprimierung im Laufwerk sind die Daten mehrfach mit Quersummen und ECC-Verfahren abgesichert, so dass sie der Softwarekomprimierung die wir mit den Programmen in Linux erreichen können, oftmals überlegen ist. Normaler Weise wird die Komprimierung schon mit dem gewähltem Datenformat gewählt und ist bei modernen Laufwerkstypen in aller Regel voreingestellt. Einige Datenformate ermöglichen jedoch unabhängig vom Schreibformat die Hardwarekomprimierung des Laufwerkes ein oder auszuschalten.

Wie das von den Softwarekomprimierungsmethoden bekannt ist, so können verschiedene Daten verschieden stark komprimiert werden. Dateien mit reinen Zufallswerten werden beim Komprimieren noch größer, schon komprimierte Daten, lassen sich sehr schlecht bis gar nicht komprimieren, Texte und Logdateien sehr gut, und Dateien mit sich ständig wiederholenden kleinen Sequenzen oder Dateien die fortwährend die gleiche Bytesequenz enthalten, lassen sich enorm komprimieren. Als Richtwert über eine goße Datenmenge der unterschiedlichsten Dateien wird meist eine Kompression von 2 zu 1 angenommen. Viele Hersteller geben die Kapazität bei Bandlaufwerken als Nativ Kapazität ( unkomprimierte Kapazität ) und komprimierter Kapazität (doppelter Nativ Kapazität) an. Aus ideologischen Gründen wird bei einigen Herstellern in Benennungen allerdings oftmals das Nativ vergessen oder irgendwo klein im Text versteckt und die komprimierte Kapazität angegeben. Wieviel Daten dann letztlich auf das Band passen, hängt aber von der Art der Daten ab. Man muss sich also nicht wundern, wenn zB auf ein DDS3 Band, das mit 24GB Kapazität angepriesen wird, dann doch nur 11 oder 12GB Bilder passen, aber nach weit über 30GB Logdateien das Band immer noch nicht voll ist.

Die Kompression sollte man wenn möglich angeschaltet lassen. In einigen wenigen Fällen kann es aber dennoch notwendig erscheinen sie abzuschalten. Mit mtst kann man die Kompression für verschiedene Laufwerke und Formate ein ( 1 ) oder ausschalten ( 0 )

LINUX > mtst -f /dev/nst0 compression 0
LINUX > mtst -f /dev/nst0 compression 1    

Ob komprimiert geschreiben wurde oder nicht, erkennt das Laufwerk beim lesen automatisch, es muss also hier nicht extra beim lesen noch einmal angegeben werden.

Wie man daraus jetzt auch sehr leicht ableiten kann, sind Optionen bei Backupprogrammen die die Kapazität des Backupmediums beschreiben und nach erreichen einer solchen gesicherten Datenmenge automatisch ein neues Medium anfordern, nicht mehr auf dem Stand er heutigen Zeit und für Bandlaufwerke nur sehr eingeschränkt von Nutzen. Sie würden nur im unkomprimierten Modus einigermaßen funktionieren. Allerdings sollte man auch bedenken, dass auch noch einige andere Faktoren die Kapazität auf einem Band trotz ausgeschalteter Komprimierung die Kapazität negativ beeinflussen. Beispiele dafür sind ungünstige Blockgrößen, die einen sehr großen Overhead erzeugen, und die Eigenschaft einiger moderner Laufwerke, die schlechte physikalische Blöcke auf dem Bandmaterial als bad markieren und diese dann später nicht mehr nutzen und somit die mögliche Gesamtkapazität des Bandes verringern.

Das Streaming Problem

Anders als zB bei Festplatten, bei denn sich runde Scheiben ständig am Schreiblesekopf vorbei drehen, wird bei Bandlaufwerken ein oft mehrere hundert Meter langes dünnes Magnetband am Schreiblesekopf vorbeigespult. Dieses Band muss sich zum lesen und schreiben immer mit bestimmten Geschwindigkeiten bewegt werden, und die Daten stehen sequentiell also logisch in einer Reihe auf dem Band. Wird das Laufwerk mit den richtigen Parametern betrieben, dann kann die Mechanik einen durchgehenden Bandtransport gewährleisten. Die Daten werden über die interne Elektronik durchgehend verarbeitet und in einem internen Puffer für den Transport über SCSI zwischengespeichert. Kann der Kopf die Daten nicht schnell genug verarbeiten, dann wird irgendwann die SCSI-Verbindung für einige Zeit unterbrochen, da das Puffer entweder leer oder voll ist. In jedem Fall dreht sich das Band immer mit gleicher Geschwindigkeit weiter. Dieses Verhalten nennt man streaming und ist die optimale Situation und sollte ständig angestrebt werden.

Bei ungünstigen oder falschen Parametern, werden am Kopf ständig mehr Daten verarbeitet, als über SCSI und interne Elektronik verarbeitet werden können. Das Ergebnis ist, die Mechanik muss für eine Moment gestoppt werden, weil keine Daten mehr zum schreiben da sind, oder die gelesenen Daten erst mal aus dem Laufwerk raus müssen. Nach kurzer Zeit kann dann wieder weitergelesen oder geschrieben werden. Jetzt muss das Laufwerk erst einmal ein Stück zurückspulen und dann der Vortrieb neu gestartet werden, damit durch die Trägheit der Mechanik dann an der richtigen Bandposition auch wieder die richtige Bandgeschwindigkeit anliegt. Bei diesem Modus wird die Mechanik also ständig gestartet und angehalten, man nennt das deshalb auch Start-Stopp-Betrieb. Die mechanische Belastung für Motoren, Antrieb, Lager und ähnlichem, sorgt hier für einen starken Verschleiß an der Mechanik. Aber auch das Bandmaterial unterliegt hier einem extrem hohem Verschleiß. Die Fehlerrate von einzelnen falsch gelesenen Bits ist in diesem Modus sehr hoch, das wird zwar durch ausgeklügelte Technologien von Einzelfehlerkorrekturverfahren wie zB ECC in einem hohem Mass wieder ausgeglichen, es kommt dennoch häufig vor, dass ein Block noch einmal komplett neu gelesen muss, was wiederum nur über ein zusätzliches Start-Stopp der Mechanik funktioniert.
Dieser Modus sollte also wenn immer möglich verhindert werden, da hier nicht nur das Risiko von Fehlern besonders hoch ist, sondern auch Bandmaterial und Laufwerk sehr schnell "altern".

Die richtige Blockgröße

Die Blockgröße ist die Option, bei der von Laufwerksunerfahrenen das meiste falsch gemacht werden kann. Deshalb soll das Problem hier etwas genauer beleuchtet werden.

Die Blockgröße (blocksize) ist die Menge an Daten die bei einem einzigem Befehl von einem Programm bei Ein- oder Ausgebeoperationen transportiert wird. Bei normalen Operationen innerhalb eine Filesystems ist das unerheblich. Das Filesystem ist im Hauptspeicher des Rechners gecacht, und der Rechner ist so schnell, dass es kaum einen Unterschied gibt, ob man 64 mal 16 Byte in den Speicher transportiert oder aber 1 mal 1024 Byte. Der Cache des Filesystems arbeitet davon unabhängig mit einer bestimmten voreingestellten Blockgröße mit der Festplatte. Anders schon, wenn wir den Cache des Filesystems umgehen. Es gibt Operationen bei denen wir direkt auf die Festplatte schreiben, unter vollkommener Umgehung des Filesystems, wenn zB. die Festplatte mittels dd gelöscht oder überschrieben werden soll. Würden wir jetzt hier mittels dd 64 mal 16 Byte auf die Festplatte schreiben, dann müssten über den Controller 64 Pakete über den IDE- , USB- oder SCSI-Bus transportiert werden, und für jedes Paket würde auf dem Bus eine oK Meldung wieder vom Laufwerk zurück über den Bus transportiert werden müssen. Das ist schon wesentlich langsamer mit einem Paket gleich 1024 Byte zu verschicken. Ist aber immer noch nicht tragisch, denn die meisten Festplatten haben intern wiederum einen Puffer. Erst wenn das Laufwerk der Meinung ist, ich muss jetzt die Daten aus dem Puffer auch wirklich auf die Festplatte schreiben, werden dann die Daten aus dem Puffer wiederum mit einer speziellen Blockgröße innerhalb der Festplatte wirklich auf die Platte geschrieben. Im ungünstigsten Fall würden wir also die Festplatte dazu verleiten einige Male ein und den selben Block auf der Festplatte zu beschreiben. Man kann also schon hier beim direkten Schreiben auf die Festplatte mit einer falschen Blockgröße unnötige Zeit verschenken. Ähnlich auch bei falschen Blockgrößen über das Internet. Im ungünstigsten Fall werden sehr sehr viele kleine Pakete übers Internet transportiert, was dann schon eine enorme Zeitverschleppung bedeuten kann.

Die selbe Übertragungsprobleme haben wir jetzt bei Bandlaufwerken auch, allerdings kommt hier noch etwas dazu. Das Laufwerk sammelt erst einmal die an ihm übertragenen Daten in einem Puffer, merkt sich allerdings immer was jetzt ein Übertragungsblock war. Ist der Puffer einigermaßen gefüllt, fängt das Laufwerk an, und schickt jeweils einen solchen Datenblock durch den Kompressor, und baut aus den jetzt unterschiedliche großen komprimierten Blöcken dann mittels Quersummen und Verwaltungs- und ECC Informationen durch aufteilen oder aneinanderreihen die Blöcke zusammen die dann wirklich physikalisch auf das Band geschrieben werden. Das bedeutet, je mehr kleine Blöcke an das Laufwerk gesendet werden, um so mehr Arbeit hat das Laufwerk mit Komprimierung und Umwandlung zu den Blöcken die geschrieben werden können. Wenn jetzt genügend physikalische Pakete vorrätig sind, dann wird die Mechanik gestartet und mit dem Schreiben begonnen. Werden jetzt nicht schnell genug physikalische Blöcke fertig, weil die Umwandlung zu lange dauert, muss das Schreiben unterbrochen werden. Wir haben den typischen Start-Stopp-Modus.

Die Laufwerke haben jetzt 2 mögliche Modus, die im Laufwerk eingestellt werden können.

• Die Laufwerke interpretieren jeden Block der über SCSI kommt als einen eigenen Datenblock. Da die Größe der Datenblöcke jetzt von der Größe abhängt die das Programm an das Laufwerk über SCSI sendet (das Programm kann sich ja beim nächsten Aufruf durchaus auch für eine andere Blockgröße entscheiden, oder sogar jeden Block mit einer völlig anderen Blockgröße über SCSI versenden), ist die Blockgröße das für die Laufwerke variabel. Man spricht deshalb von variabler Blockgröße

Eingestellt wird dieser Modus mit der Option ( 0 ) und die eingestellte Größe kann man bei geladenem Band mittels Status ermitteln.

root@LINUX:/ # mtst -f /dev/nst0 setblk 0
root@LINUX:/ # mtst -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x27 (Exabyte Mammoth).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

• Oder dem Laufwerk wird angewiesen, egal wie groß die Blöcke sind, die über SCSI reinkommen, du machst daraus immer Blöcke einer festen Größe. Ist die Bockgröße über SCSI zu groß, dann werden die Blöcke aufgeteilt, ist die Blockgröße zu klein, dann füllst du die Daten einfach mit NULLen auf die richtig Länge auf. Dieser Modus nennt man feste Blockgröße

Eingestellt wird dieser Modus mit der genauen Angabe der Blockgröße in Byte, Abfrage ebenfalls bei geladenen Band mittels status.

root@LINUX:/ # mtst -f /dev/nst0 setblk 1024
root@LINUX:/ # mtst -f /dev/nst0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 1024 bytes. Density code 0x27 (Exabyte Mammoth).
Soft error count since last status=0
General status bits on (41010000):
 BOT ONLINE IM_REP_EN

Doch damit noch nicht genug. Die Daten sollen ja auch irgendwann mal wieder aus dem Laufwerk gelesen werden. Das Backupprogramm gibt also den Befehl, "gib mir einen Block Daten vom Band" an das Laufwerk über SCSI heraus. Das Laufwerk liest jetzt einige physikalische Blöcke vom Band, nimmt den ersten und extrahiert daraus den ersten komprimierten Block, und dekomprimiert diesen. Dieser Block hat jetzt genau die selbe Größe, wie damals als er geschrieben wurde. Hat jetzt allerdings das Programm eine andere Blockgröße über SCSI angefordert, als zum Zeitpunkt des Schreibens der Daten, dann ist der Block im Laufwerk jetzt entweder zu klein oder zu groß für die Größe die über SCSI vom Backupprogramm jetzt abgeholt werden soll. Entsprechend der unterschiedlichen Einstellungen kann jetzt folgendes passieren:

• das Laufwerk gibt eine Fehlermeldung
• was zu viel ist wird abgeschnitten und geht bei der Übertragung verloren
• ein zu kleiner Block wird mit Nullen aufgefüllt.
• das Laufwerk füllt einen zu kleinen Block mit Daten aus dem nächstem Block auf

Man kann sich also an 2 Fingern abzählen, dass das Backupprogramm nicht in jedem Fall die Daten auch wieder richtig herstellen kann, wenn beim Speichern und Lesen mit unterschiedliche Einstellungen der Blockgrößen gearbeitet wird.

Es gilt also:

• Immer mit der selben Blockgröße lesen, mit der geschrieben wurde
• Ob man mit variabler oder fester Blockgröße arbeitet sollte für dieses Laufwerk an diesem Rechner klar festgelegt werden, da diese Einstellung im Laufwerk gespeichert wird, und erst über einen Befehl oder durch Reset des Laufwerks geändert wird. In den meisten Fällen wird mit variabler Blockgröße gearbeitet. Dann haben auch unterschiedliche Backupprogramme auf dem selbem Rechner die Gewissheit, dass die in ihnen festgelegten Blockgrößen richtig verarbeitet werden.

per Voreinstellung werden sich die meisten Laufwerke nach einem Reset auf eine feste Blockgröße (meist 512 oder 1024) einstellen. Es muss also in jedem Fall eine Einstellung der Blockgröße auf variable oder größeren festen Wert vor der ersten Benutzung des Laufwerkes nach dem Start von Linux vorgenommen werden.

• Kleine Blockgrößen immer vermeiden.

Welche Blockgrößen jetzt für welches Laufwerk optimal ist, hängt vom Laufwerkstype ab. bei Blockgrößen unterhalb von 8 KB sinkt bei allen Laufwerken die Performance in den Keller, und der Start-Stopp-Modus ist garantiert.

Blockgrößen die nicht durch 512 teilbar sind, werden von einige Laufwerken nicht unterstützt. In den meisten Fällen wird man 4 8 16 32 64 128 256 (jeweils KB) benutzen.

Für ältere Laufwerk sind Blockgrößen von 32KB 48KB 64KB 96KB geeignet.

bei moderne Laufwerken ist die optimale Blockgröße gleich der eingestellten maximale Blockgröße die SCSI in LINUX erlauben würde also 256 KB

• Blockgrößen die zu groß für das Laufwerk sind, werden vom Laufwerk mit Fehlermeldung quittiert. Solche Grenzen liegen bei modernen Laufwerken jedoch oftmals oberhalb von 1MB
• Die Blockgröße für SCSI ist auch beschränkt, bei LINUX bei 256 KB. Wird diese überschritten, dann kommt je nach Konfigurationseinstellungen entweder ein Fehler vom Kernel, oder es werden die zu großen Blöcke innerhalb des SCSI-Treibers in mehrere Blöcke geteilt. (Beispiel: 384KB werden aufgeteilt in 256Kb und 128KB) Ein solches stillschweigendes Aufteilen der Blöcke bleibt oft unbemerkt. Moderne Backupprogramme werden jedoch beim Positionieren auf einzelne Dateien Probleme bekommen, da der Index der Blöcke vom Backupprogramm nicht dem entspricht, wie die Blöcke vom Laufwerk auf das Band geschrieben werden.

weiter Links zum Thema Linux Backup auf Tapelaufwerken

• Script für Backup erklärt das Schreiben eines eigenen konfortablem Backupscript für Tapelaufwerke von Grund auf.

--Robi 18:51, 12. Nov 2006 (CET)