Teer auf Band: Blocknummer und Blockierungsfaktor

2757
idrevettenome

Die 64-kiB-Blockgröße dient zur Maximierung des Durchsatzes und zum Vermeiden von "Schuhglänzen".

mt -f /dev/nst0 setblk 64k  tar -c -v -R -b128 -f /dev/nst0 test_dir

kehrt zurück:

bloc 0 : test_dir/ bloc 1 : test_dir/file_1.bin bloc 204802 : test_dir/file_2.bin bloc 2252803 : test_dir/file_3.bin bloc 4300804 : test_dir/file_4.bin ...

Die Blocknummer in der tarAusgabe entspricht jedoch 512 B Blockgröße, obwohl der Blockierungsfaktor 64 kiB Blockgröße (128 * 512) ergibt.

Und dann, unabhängig von der Blockgröße des Befehls mt (Variable, 64 kiB).

Das Ziel wäre ein wahlfreier Zugriff auf das Tar-Band. Konvertieren Sie 64 kiB-Blöcke in 512, um sie zu trimmen.

Gibt es eine Möglichkeit, Datensätze von tarund mtabzugleichen?

0
Auszüge aus Man-Seiten des Befehls `st` (detaillierter als` mt`): _italic_Many-Programme (z. B. `tar (1)`) ermöglichen es dem Benutzer, den Blockierungsfaktor in der Befehlszeile anzugeben. Beachten Sie, dass dies die physikalische Blockgröße auf dem Band nur im Modus mit variablen Blöcken bestimmt._italic_ idrevettenome vor 8 Jahren 0
Wie ich oben schon erwähnt habe, habe ich es mit mt -f / dev / nst0 setblk 0 versucht. Im Forum gesehen: _italic_tar / dd / welche Blocksize! = (SCSI) - Bandgerätetreiberblock _italic_ ([http://www.linuxmisc.com/14-unix-administering/b290ded6513059e2.htm]) idrevettenome vor 8 Jahren 0

2 Antworten auf die Frage

0
rayzinpwr

UPDATE: Arg! Soviel zu Tests. Nur ein vollständiges Backup und tar mit seiner Standard-Block- / Datensatzgröße lief um etwa 25% langsamer. Also benutze ich wieder -b2048. Versuchen Sie -b1024 und sehen Sie, wie es geht.

Okay, hab nur ein paar Tests gemacht. Mein Rat ist, die Bandblockgröße auf 0 (variabel) zu setzen und einen Tar-Block / Datensatz Ihrer Wahl auszuwählen. Ich habe mit einer Bandblockgröße von 1M und 512K mit übereinstimmenden Tar-Datensatzgrößen getestet (-b2048 = 1M -b1024 = 512K), dann habe ich die Bandblockgröße auf 0 gesetzt und mit tar -b2048 und -b1024 getestet, und es gab keinen Unterschied . Dann führte ich erneut einen Test mit 'setblk 0' durch, jedoch mit einer Standard-Tar-Blockgröße von 512 (kein -bxxxx), mit einer Gesamtlänge von 10240 Bytes und immer noch keinen Leistungsunterschied.

Ich verwende einen Quantum LTO-5. Solange Sie wesentlich über 512 Bytes sind (der LTO-5-Standard ist meiner Meinung nach), sollten Sie in Ordnung sein und es ist unwahrscheinlich, dass Sie einen Schuhglanz erleben werden. IMO, der einzige Grund für das Festlegen der Laufwerksblockgröße (anstelle von Variablen) ist, wenn die Softwareblockgröße (Datensatzgröße bei tar) ignoriert wird.

Hinweis: Die Standardblockgröße für tar beträgt 512 Byte x 20 für eine Gesamt- "Datensatzgröße" von 10240 Byte. Übrigens, meine Tests waren alle innerhalb von 12 Sekunden abgeschlossen, was ~ 141.000.000 Bytes / Sekunde ergibt, der maximale Durchsatz des LTO-5.

0
Abner

Meine Ergebnisse mit --blocking-factor verwenden tar-to-tape auf mehreren tar-Archiven mit einer Größe von 200 bis 300 GB.

  • Blockierungsfaktor 256 Durchsatz 62 bis 68 MiB / Sek.

  • - Blocking-Faktor 1024 Durchsatz 87 MiB / Sek.

Ich habe vor, mit noch größeren Blockierungsfaktoren zu experimentieren.

Oben mit Standard-Hardware-Blockgröße (ich denke variabel) und keine Komprimierung erhalten.

Meine Ausrüstung unten aufgeführt:

  • HP EH958B StorageWorks Ultrium 3000 LTO-5 1,5 / 3 TB SAS (Serial Attached SCSI) Externes Bandlaufwerk halber Bauhöhe LTO5

  • TDK LTO-5 Ultrium Data Cartridge LTO-Ultrium-5-Band mit 1,5 TB / 3,0 TB

  • ATTO-Technologie ExpressSAS H680 PCIe 2.0-SAS-HBA-Karte mit niedrigem Profil (6 Gbit / s) (externe Anschlüsse) Bestellnr .: ESAS-H680-000

Verwandte Probleme