• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Autoloader beschreibt die einzelnen Bänder nicht bis zum End

aerosol

Newbie
Hi,

ich habe einen Autoloader, den ich auch problemlos mit mtx steuern kann. Dieser Autoloader beinhaltet 8 Bänder mit je 400/800GB Kapazität. Da die bisherige Größe der zu sichernden Daten bei ca 180GB liegt, sollte ich also locker mit einem Band auskommen. Allerdings bricht er die Bandsicherung nach ein paar Stunden ab, mit der Meldung:

No More Tapes

Also ist er der Meinung das er alle 8 Tapes vollgeschrieben hat, was unmöglich ist!

Nachdem ich nun das Sicherungsscript (per tar wird gesichert) um ein -v erweitert habe konnte ich nun feststellen, das er nach ca. 8GB schon zum 2. Band wechselt! Deshalb habe ich die Option:

--tape-length=409600000

eingeführt, was aber auch keine Abhilfe brachte!


ganzes Sicherungsscript sieht wie folgt aus:

Code:
#!/bin/sh

# Status des autoloaders ausgeben
/usr/sbin/mtx -f /dev/sg1 status

# 1. Band laden
echo "1. Band laden"
/usr/sbin/mtx -f /dev/sg1 first

#Band zurueckspulen
time /usr/bin/mt -f /dev/st0 rewind

#Start der Sicherung
#
time tar --new-volume-script=/bin/nexttape --tape-length=409600000 --totals -cMvf /dev/st0 /home/* 

echo "Daten erfolgreich gesichert!"

#Ueberpruefung
echo
echo "...die Ueberpruefung.."
echo

#1. Band laden, bei Bandsicherung ueber mehrere Baender
/usr/sbin/mtx -f /dev/sg1 first
tar --new-volume-script=/bin/nexttape -tMf /dev/st0 > /dev/null

echo "Ruecksicherung Ende"

#Entladen des Bands
echo "Band entladen"
/usr/sbin/mtx -f /dev/sg1 unload
echo
echo "Sicherungsskript ende!!!"

Ich habe zusätzlich mal versucht das Band zu löschen mittels:

#Band loeschen
time /usr/bin/mt -f /dev/st0 erase

was sich aber zu einer endlosen Geschichte entwickelte mit dem Ergnis, das der Prozess mt den Status D an nahm und somit ein reboot des Servers nötig macht!


Kann wer helfen? Muss ich evtl. irgendwo anders die Größe des Bandes angeben? Auch das mit dem zurück spulen und löschen des Bandes, war beim bisherigen Bandlaufwerk nicht nötig!

Ach ja der Autoloader ist ein:
ADIC FastStor 2.1

und das Bandlaufwerk in dem Autoloader:
HP Ultrium 3-SCSI

p.s. Es handelt sich um ein SuSE 9.0


Danke im voraus

aerosol
 
A

Anonymous

Gast
Du hast eine recht nette Jukebox mit scheinbar LTO2 oder LTO3 Laufwerk(en), aber ich glaube fast recht wenig Ahnung von dieser Technologie.

Diese Laufwerke benötigen um irgendwie in einem einigermaßen verträglichen Arbeitsbereich arbeiten können eine Blocksize von Minimum 64kB und eine Datendichte von über 10MB/s (LTO2 hätten am liebsten über 17MB/s bei unkomprimierbaren und ungefähr das doppelte bei komprimierbaren Daten, LTO3 hätte dann gerne nochmal das Doppelte )
Die Blocksize kannst du außerhalb des Scriptes festgelegt haben, aber schon die Angabe der Zeit von mehreren Stunden für 190GB lassen mich ins Zweifeln kommen. Auch ist hier tar für solche Laufwerke und regelmäßigen Sicherungen sicherlich nur die absolute Notlösung. Besser ist hier eine professionelles Backupprogramm. Es würde ja auch niemand ein Formel 1 Auto zum einkaufen in der Stadt benutzen.

Ansonsten sind für solche Laufwerke oftmals noch spezielle Einstellungen an den Treiber vorgeschlagen. Auch kannst du mal in die /var/log/messages schauen, je nach dem wie das Loging in den Treibern eingestellt ist, könntest oder solltest du dort mehr oder weniger ausführliche Meldungen vom kernel und dem st-Treiber haben, wenn das Band als voll erkannt wird. Schau da mal rein ob du da was findest und gib das mal rüber. Mal sehen ob ich helfen kann.

Ansonsten würde ich mir mal den Verkäufer dieser Kiste zur Brust nehmen und nach empfohlener Backupsoftware und Anschlusskonzept dafür fragen. Im Zweifelsfall finde ich auch jemanden der dir sowas gerne verkaufen würde.

robi
 
OP
A

aerosol

Newbie
Also ich verwende nun seit gestern ein anderes Tool und zwar:

http://www.i-synapse.it/portal/it/products/opensource/synbak/overview

gefällt mir eigentlich auch ganz gut, nur bekomme ich einfach nicht mit genug dampf drauf geschrieben!

Das "Tool" schreibt auch mit dem tar Befehl und zwar mit folgendem:

Code:
linux # ps ax | grep tar
23062 pts/1    R+     0:12 tar --exclude-from=/tmp/synbak-1151660890-8173-lsltp-tape/list_unbackable --exclude-from=/tmp/synbak-1151660890-8173-lsltp-tape/list_exclude --totals -b 128 -cpf /dev/st0 /home/abeln_m/downloads

Somit also mit einer Blocksize von 128. Hälst du das für sinnvoll? die stats wären folgende:

Code:
#  	System  	Method  	Option  	Type  	Begin  	End  	Duration  	Bak. Size  	Speed  	Tot. Size  	Result
14)  	lsltp 	tape 	  	local 	20:00:02 	05:50:20 	09:50:18 	82.26 GB 	2.32 MB/Sec 	82.26 GB 	OK

================================================================================
         Backup end: 2006/06/30 05:50:20 CEST
        Backup size: 82.26 GB
       Backup speed: 2.32 MB/Sec
        Source size: 126.80 GB
    Backup duration: 09:50:18
      Backup result: OK
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Das es so extrem langsam war, erkläre ich mir dadurch, das er so oft aussetzten muste, wegen der folder mit Umlauten, die er nicht erreichen konnte!

Also gestern von einem NFS-share hatte ich ,mit einer 1gigabit ethernet Verbindung zu unserem Netapp Filer, ca 17mb/s allerdings. Von einem smb share allerdings nur 6mb/s und das nur ohne Umlaute :/ Wenn ich vom Filer als cifs moutnen will, bekomme ich immer die Fehlermeldung:

Code:
linux # l
/bin/ls: reading directory .: Cannot allocate memory

obwohl genügend Speicher zu Verfügung steht:

Code:
linux # free
             total       used       free     shared    buffers     cached
Mem:       2595744    2578168      17576          0          0    1919840
-/+ buffers/cache:     658328    1937416
Swap:      1762536          8    1762528

und cifs mount von anderen Windows Freigaben gehen auch ohne Probleme!
 

tux486

Member
Grüß Gott,
ich würde Dir empfehlen, die zu sichernden Daten lokal zwischenzuspeichern und erst dann an die LTOs zu schicken, um einen kontinuierlichen Datenstrom zu gewährleisten. Wenn die Dinger keinen solchen Datenstrom bekommen und immer wieder anhalten müssen, um auf die Daten zu warten, ereilt sie ein schneller Tod...

Guck mal auf www.useddlt.de und www.usedlto.de für weitere Informationen zu DLT und LTO Laufwerken.
 
A

Anonymous

Gast
Zum Thema Blocksize auf Tapes hatten wir hier schon ein paar Beiträge,
schau mal hier durch, und mal den Links hier im Forum folgen.
http://www.linux-club.de/viewtopic.php?t=52517&highlight=blocksize
Damit solltest du erst mal einiges zu lese haben.

Kurz zur Blocksize
Per Voreinstellung beim st-Treiber bekommt das Bandlaufwerk einen festen Wert von ich glaube 512Byte mitgeteilt. Wenn du diesen Wert nicht änderst, dann kannst du mit tar oder cpio oder dd Blockgrößen schicken so groß du willst, das Laufwerk macht daraus erst mal 512Byte Blöcke, und verarbeitet so kleine Blockgrößen, das es sich fast tot-rackert aber kaum Daten schreiben kann.

Für LTO Laufwerke würde ich empfehlen wenn man mit einem niederem Backupprogramm (tar usw) arbeitet, 128KB besser noch 256KB (größer als 256 ist nicht zu empfehlen, es gibt uU Konfigurationen die damit im Treiber oder Kernel nicht funktioniern, oder der Treiber dann stillschweigend größere Pakete in ein Paket von 256KB und ein Paket in den Rest oder wieder 256KB teilt.)
Dazu die Blockgröße im Laufwerk auf "NULL" setzten, ( das braucht man nur einmal machen, und bleibt bis zum nächsten Boot oder Reset der Laufwerkes im Laufwerk aktiv, man darf es aber durchaus gerne jedes mal beim Start des Backupscriptes sicherheitshalber absetzen) dann verarbeitet das Laufwerk die Blöcke wie sie von der Sicherungssoftware geschickt werden.

mit tar Option -b N wobei die Blockgröße dann N* 512byte ist
bei cpio Option -C
bei dd Option bs= oder obs=

Wichtig beim zurücklesen der Daten muss dann wieder das Laufwerk auf NULL gesetzt werden und die Daten mit der gleichen Blockgröße wie beim Schreiben gelesen werden

robi
 
OP
A

aerosol

Newbie
tux486 schrieb:
Grüß Gott,
ich würde Dir empfehlen, die zu sichernden Daten lokal zwischenzuspeichern und erst dann an die LTOs zu schicken, um einen kontinuierlichen Datenstrom zu gewährleisten. Wenn die Dinger keinen solchen Datenstrom bekommen und immer wieder anhalten müssen, um auf die Daten zu warten, ereilt sie ein schneller Tod...

Guck mal auf www.useddlt.de und www.usedlto.de für weitere Informationen zu DLT und LTO Laufwerken.

Das mit dem zwischenspeichern ist ein wenig problematisch, da die größe des Backups weit die Größe der lokalen Platte überschreitet! Oder meinst du immer so ein paar GB ansammeln und dann anfangen mit dem schreiben aufs BandlaufwerK? Wie könnte man soetwas realisieren?


@robi

danke werde ich bei gelegenheit mal anfangen zu lesen, nur leider is das ding nun shcon hier und muss mögllichst schnell ordentlich funktionieren!
 
A

Anonymous

Gast
aerosol schrieb:
Das mit dem zwischenspeichern ist ein wenig problematisch,
..
Oder meinst du immer so ein paar GB ansammeln und dann anfangen mit dem schreiben aufs BandlaufwerK? Wie könnte man soetwas realisieren?

Ja genau so, aber glaube mir, das ist gar nicht so einfach und muss wohl mit einer "richtigen" Programmiersprache geschreiben werden, mit Shell ist da nichts zu machen. (Am besten gleich wieder vergessen, für Otto-Normal und Kleinanwender muss man eben seine Laufwerke sogut es eben irgendwie geht versorgen, doch dazu muss man eben einiges bedenken wenn man die modernen Laufwerk benutzt.)
Aber funktioniert im Prinzip wie folgt, du sammelst mit einem Prozess die Dateien von mehrern Servern oder Laufwerken im Speicher, und mit einem 2 Prozess presst du die Daten zyklisch oder kontinuirlich je nach dem wie schnell sie kommen, aus dem Speicher auf das Laufwerk. Irgendwer hatte da mal geschrieben, es gäbe da auch ein Programm oder Tool das man als Cache für ein Backup dazwischenschalten kann. Muss auch irgendwo mit dem obrigen Link zu finden sein, habe ich aber noch nie gefunden oder getestet.
Nur mal so zu Info für alle die es intressiert, im großen Maßstab gibts solche Dinger schon, aber als Hardware_Lösung.
Da hast du Server die einen großen Raid mit schnellen Platten haben. Diese Server simulieren dann Bandlaufwerke und sichern die Daten im Raid. Von dort aus werden die logischen Bänder dann von anderen Servern auf Physikalische Laufwerke und physikalische Bänder geschreiben. zB. hier (keine Werbung nur zur INFO)
http://www.fujitsu-siemens.de/products/storage/centricstor/
ist aber bestimmt auch die teuerste Lösung und nicht für 1 bis 10 Rechner oder Server gedacht.


robi
 

tux486

Member
robi schrieb:
Irgendwer hatte da mal geschrieben, es gäbe da auch ein Programm oder Tool das man als Cache für ein Backup dazwischenschalten kann. Muss auch irgendwo mit dem obrigen Link zu finden sein, habe ich aber noch nie gefunden oder getestet.

Meinst Du mich und das Progrämmelchen "buffer" ?
8)

"buffer" v1.19-706 wurde gemäß SuSE 9.0 Paketbeschreibung von Lee McLoughlin (L.McLoughlin@doc.ic.ac.uk) geschrieben.
"Ausführliche Beschreibung" in YaST:
This is a program designed to speed up writing tapes on remote tape drives. When this program is put "in the pipe", two processes are started. One process reads from standard-in and the other writes to standard-out. Both processes communicate via shared memory.
Habe leider grade keine neuere SuSE zur Hand und weiß nicht, ob es noch mitgeliefert wird (gemäß rpmseek soll es eine Version 1.19-709 für SuSE 9.3 geben).


Ha! Doch:
http://ftp.gwdg.de/pub/opensuse/distribution/SL-10.1/inst-source/suse/i586/buffer-1.19-720.i586.rpm
Version 1.9-720 für SuSE 10.1
 
OP
A

aerosol

Newbie
Hey Super jungs! Das werde ich morgen gleich mal asuprobieren, wenn ich dann noch das mit den Umlauten zum laufen bekomme (evtl mit ner neuren Samba Version) wäre es ja klasse. Melde mich dann morgen nochmal!
 
OP
A

aerosol

Newbie
ok habe das nun mit dem buffer eingebunden:

Code:
tar --exclude-from=/tmp/synbak-1151943244-24459-lsltp-tape/list_unbackable --exclude-from=/tmp/synbak-1151943244-24459-lsltp-tape/list_exclude --totals -b 256 -cf - /home/abeln_m/downloads | buffer -o /dev/st0

allerdings hat das nun auch nich die super werte gebracht. ich lag immer noch bei ca. 7MB/s :( aber heute nacht mal abwarten, was das Backup bringt...


Zu den Umlauten:

Also die Idee war, die gleich eSamba Version, welcher erfolgreich auf meinem Client System (SuSE 10.1 samba-client-3.0.23-0.1.14rc2) mit dem Filer zusammen arbeiten, zu nutzen. Welches eine riesen Abhängigkeitsschlacht mit sich zog, welche ich unmöglich zuende bringen konnte :( Somit hab ich die Version von der Service Pack 3 des SLES genommen (samba-client-3.0.20b-3.4.i586.rpm). Diese macht nicht mehr sooo viele Probleme, aber ich bekomme trotzdem noch in regelmäßigen abständen die ^^ Meldung: Cannot allocate Memory...

Scheint als würde ich so nich viel weiter kommen und zu einer Kostenpflichtigen Backup Software Lösung greifen müssen?! Achja wegen des cifs Problems habe ich bei NetApp niemanden erreichen können (tolle Hotline, hab enoch andere Sachen zu tuen ausser in der Warteschleife zu warten).

MfG

aerosol
 
A

Anonymous

Gast
hast du den jetzt mal die variable Blockgröße im Laufwerk eingestellt?
ich nutze mtst auf LINUX dazu, hat mehr Optionen und genauere Ausgaben als mt, muss aber eventuell noch nachinstalliert werden.
Code:
 mtst -f /dev/nst0 setblk 0
an den Anfang deines Scripts setzten,
erst dann kann die Blockgröße aus tar auch im Laufwerk verarbeitet werden.

gib auch mal ein mtst -f /dev/nst0 status hier zum Besten, wenn eine Kassette eingelegt ist.

robi
 
OP
A

aerosol

Newbie
ja wie bei in meinem letzten Post zu entnehmen ist, habe ich die Blocksize auf 256 geändert /ist wahrscheinlich in dme langen tar Befehl untergegangen) allerdings habe ich den wert vorher nicht mittels mtst zurück gesetzt, werde ich morgen sofort mal ausprobieren! Danke!

MfG

aerosol
 
OP
A

aerosol

Newbie
ich bekmm einfach keine vernünftige geschwindigkeit hin! auch nicht mein deinem letzten rat! :(


Oder soltle ich evtl AMANDA nehmen als Backupsoftware? Jm damit erfahrungen gesammelt? Hab nämlich gelesen:"Von den Funktionen her kann sich Amanda mit Arkeia messen."

liegt es evtl an meinem Netzwerk?

bonnie ausgabe aufs cifs share:

Code:
# bonnie
Bonnie 1.4: File './Bonnie.13379', size: 104857600, volumes: 1
Writing with putc()...         done:   3973 kB/s  31.4 %CPU
Rewriting...                   done:   3460 kB/s   9.4 %CPU
Writing intelligently...       done:   4901 kB/s  10.4 %CPU
Reading with getc()...         done:   3015 kB/s  21.0 %CPU
Reading intelligently...       done: 223343 kB/s  98.6 %CPU
Seeker 1...Seeker 3...Seeker 2...start 'em...done...done...done...
              ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek-
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)-
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU   /sec %CPU
lsltp  1* 100  3973 31.4  4901 10.4  3460  9.4  3015 21.0223343 98.6 1113.6 25.4

bonnie ausgabe aufs smb share:

Code:
# bonnie
Bonnie 1.4: File './Bonnie.14239', size: 104857600, volumes: 1
Writing with putc()...         done:   5059 kB/s  36.3 %CPU
Rewriting...                   done:   2487 kB/s   4.8 %CPU
Writing intelligently...       done:   7189 kB/s   8.7 %CPU
Reading with getc()...         done:   3107 kB/s  21.4 %CPU
Reading intelligently...       done: 231669 kB/s  99.8 %CPU
Seeker 2...Seeker 1...Seeker 3...start 'em...done...done...done...
              ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek-
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)-
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU   /sec %CPU
lsltp  1* 100  5059 36.3  7189  8.7  2487  4.8  3107 21.4231669 99.8 1107.7 20.7


bonnie ausgabe aufs nfs share:

Code:
# bonnie
Bonnie 1.4: File './Bonnie.3282', size: 104857600, volumes: 1
Writing with putc()...         done:  10138 kB/s  76.9 %CPU
Rewriting...                   done:  20189 kB/s  51.0 %CPU
Writing intelligently...       done:  27684 kB/s  65.4 %CPU
Reading with getc()...         done:  15029 kB/s  98.3 %CPU
Reading intelligently...       done: 191534 kB/s  97.4 %CPU
Seeker 1...Seeker 3...Seeker 2...start 'em...done...done...done...
              ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek-
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)-
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU   /sec %CPU
 1* 100 10138 76.9 27684 65.4 20189 51.0 15029 98.3191534 97.4 9855.6  107

gerade die Werte bei smb und cifs beunruhigen mich bei einem gb/s LAN! Alle Verbindungen sind direkt zum Filer
 
OP
A

aerosol

Newbie
So ich bin nun an eine Demo Version von Arkeia gekommen und habe mir auf der lokalen Platte ca 20GB in 5 files gesplittet hinggelegt um diese zu sichern.

Soweit ich das verstanden habe, sollte dass das optimale fressen für ein LTO3 sein!?!

Jedoch bekomme ich lediglich eine temporäre Maximale Übertragungsrate von 15MB/s hin!

Ausgabe der Mail von Arkeia:

Code:
From root@name.localnet.localdomain  Wed Jul 19 11:32:11 2006
X-Original-To: root@localhost
Delivered-To: root@name.localnet.localdomain
To: root@localhost.localnet.localdomain
Subject: Arkeia backup report
Date: Wed, 19 Jul 2006 11:32:11 +0200 (CEST)
From: root@name.localnet.localdomain (root)

Backup server       : name.localnet.localdomain
Backup start        : 2006/07/19 11:09:41
Backup type         : Total
Savepack            : NullPack
Drivepack           : Null Pack
Pool                : NullPool
Backup end          : 2006/07/19 11:32:01
Backup statistics   : "8" files, "15449" MB, compressed at "1.0", "1339" seconds, "692" MB/mn

Used tapes          :
                     NulTape

Flow 1
---------
2006/07/19 11:31:31 [1] Backup of "name.localnet.localdomain!file:/tmp/Image" OK, "8" files, "15449" MB, "1278" seconds, "725" MB/mn, "0" warnings


In dieser Situation soltle ich doch locker an meine 50MB/s und mehr kommen! oder nicht?

Evtl ist der Server einfach nicht dafür ausgelegt! :(

Also wenn ich mir die bonnie Ausgaben mal anschaue von der lokalen Platte und die vom Netzwerk:

lokal:

Code:
# bonnie
Bonnie 1.4: File './Bonnie.1004', size: 104857600, volumes: 1
Writing with putc()...         done:  14416 kB/s  99.6 %CPU
Rewriting...                   done: 117685 kB/s  99.9 %CPU
Writing intelligently...       done: 180699 kB/s 100.0 %CPU
Reading with getc()...         done:  15690 kB/s 100.0 %CPU
Reading intelligently...       done: 239365 kB/s  99.3 %CPU
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
              ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek-
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)-
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU   /sec %CPU
name 1* 100 14416 99.6180699  100 117685 99.9 15690  100239365 99.3 29778.5  183

Netzwerk:

Code:
bonnie
Bonnie 1.4: File './Bonnie.1020', size: 104857600, volumes: 1
Writing with putc()...         done:   4126 kB/s  36.2 %CPU
Rewriting...                   done:   4056 kB/s  12.3 %CPU
Writing intelligently...       done:   5396 kB/s  15.3 %CPU
Reading with getc()...         done:   5384 kB/s  37.6 %CPU
Reading intelligently...       done: 240557 kB/s  99.8 %CPU
Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done...
              ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek-
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)-
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU   /sec %CPU

So wirklich überzeugende Werte sind das nun ja auch nicht! :/
 

tux486

Member
Grüß Gott,

hattest Du mal bei www.useddlt.de geschmökert?
Da findet sich unter anderem auch ein Hinweis darauf, daß buffer nur 20 MB Puffer kann und daß stattdessen für größeren Pufferbedarf besser mbuffer benutzt wird.
Des Weiteren ist auch eine Abhandlung zur Daten-Übertragungsrate ganz aufschlußreich.

Vielleicht hilft Dir diese Seite ja weiter.
Vielleicht sind auch nur ganz einfach die Sicherungsmedien (Bänder) "im Eimer"?
Mangels so einer Sicherungstechnik (habe nur ein uraltes DLT TZ87 irgendwo in der Bastelecke) kann ich Dir keine exakten Lösungsvorschläge geben. :?
 
A

Anonymous

Gast
tux486 schrieb:
Des Weiteren ist auch eine Abhandlung zur Daten-Übertragungsrate ganz aufschlußreich.
Sicherlich ist die Seite aufschlussreich besonders der Satz
Alle Hersteller ohne Ausnahme wollen sich und ihre Produkte immer mit möglichst hohen Werten wie im "Guinnes Buch der Rekorde" schmücken. Die höchsten Giga Hertz Werte, die größten Gigabyte Platten, die höchsten Raid-Kapazitäten und die höchsten Datenraten - 20MB/sec, 30MB/sec, 40MB/sec und noch mehr.

Macht das alles Sinn ?
Meine private Meinung dazu:
Die Herren Verkäufer scheuen zur Zeit nicht davor zurück ihre LTO2 und LTO3 Produkte an den noch so kleinsten Kunden verkaufen zu wollen. LTO1 was noch einigermaßen zu händeln währe wird schon gar nicht mehr produziert.
Diese Geräte haben Hunger ohne Ende und hätten gerne Datenraten jenseits von gut und Böse. Werden diese Laufwerke jedoch sehr weit nach unten gedrosselt, in dem sie nicht genug Daten zum streamen bekommen, so erhöht sich 1. der Verschleiß vor allem am Bandmaterial und unsere Erfahren zeigen das die Fehlerrate und Anfälligkeit um einige 10er Potenzen steigen kann, somit leidet die Zuverlässigkeit und es gibt regelmäßig Ärger wegen nicht sauber durchlaufenden Sicherungen. Und wenn ich mir anschaue wo die Jungens in den nächsten Jahren noch hin wollen http://www.ultrium.com/newsite/html/format_datasheet.html und das wollen sie auch noch verkaufen :wink: da denke ich müssen aber bis dort hin noch Rechner entwickelt werden bei denen man die CPU- und IO-Leistung mit grünem Schleim Eimerweise aufrüsten kann, damit man den Hunger der Laufwerke auch nur annäherungsweise stillen kann.

robi
 
OP
A

aerosol

Newbie
tux486 schrieb:
Grüß Gott,

hattest Du mal bei www.useddlt.de geschmökert?
Da findet sich unter anderem auch ein Hinweis darauf, daß buffer nur 20 MB Puffer kann und daß stattdessen für größeren Pufferbedarf besser mbuffer benutzt wird.
Des Weiteren ist auch eine Abhandlung zur Daten-Übertragungsrate ganz aufschlußreich.

Vielleicht hilft Dir diese Seite ja weiter.
Vielleicht sind auch nur ganz einfach die Sicherungsmedien (Bänder) "im Eimer"?
Mangels so einer Sicherungstechnik (habe nur ein uraltes DLT TZ87 irgendwo in der Bastelecke) kann ich Dir keine exakten Lösungsvorschläge geben. :?


tar cf - /tmp/speedtest/ | mbuffer | tar tf - > /dev/st0
tar: Removing leading `/' from member names
68964.1 kB/s in - 68944.2 kB/s out - 7651040 kB total - buffer 0% full
tar: Error in writing to standard output
tar: Error is not recoverable: exiting now

irgendwas läuft da wohl nich rund! evtl liegts am mbuffer selbst !?
 
A

Anonymous

Gast
aerosol schrieb:
tar cf - /tmp/speedtest/ | mbuffer | tar tf - > /dev/st0

Wo hast du denn diese Zeile her, erst legst du ein Archiv an, dann schickst du es durch ein Buffer und dann packst du es aus und willst die Dateinamen mit Ausgabeumlenkung in eine Datei /dev/st0 schreiben. Das würde ich mir als LINUX auch nicht gefallen lassen. :wink:

sowas hier in der Art könnte da schon ehr funktionieren
Code:
tar -c -b 128 -f - /tmp/irgendwas | mbuffer | dd of=/dev/nst0 bs=65536
(ist aber ungetestet ich hab mich immer noch nicht mit diesem Bufferdingens da beschäftigt.)

robi
 

tux486

Member
Grüß Gott,

Code:
tar cfM - /mnt/mein-Server-Volume/ -b 128 | mbuffer -m 400M -p 95 > /dev/nst0
(Seite "tar" tuning von useddlt.de) lief bei mir gestern Abend mit dem uralten TZ87 DLT Laufwerk (soll einem DLT2000 entsprechen) durch, nachdem im tar-Befehl der "b" Parameter umgestellt wurde (ohne "M"):
Code:
tar -c -b 128 f - /mnt/mein-Server-Volume/ | mbuffer -m 400M -p 95 > /dev/nst0

Wobei vermutlich je nach verwendetem Laufwerk mit "-b" bei tar und je nach verwendetem Rechner bzw. dessen Ausstattung mit "-m" bei mbuffer "herumgespielt" werden muß, bis das Laufwerk durchläuft und nicht zwischendurch immer wieder anhält.
Dazu weiß robi mit an Sicherheit grenzender Wahrscheinlichkeit mehr und kann nach meiner Einschätzung ganze Bücher darüber schreiben ;)

Bei meinem ad-hoc-Test mit o.g. Zeile lief das alte TZ87 ganz passabel durch (mit wenigen Stoppern) und schrieb -woah- 480 MB in 100 Sekunden auf das Band (P-III 450, 256 MB RAM).
Vielleicht sollte ich das wieder mal nutzen :?
 
Oben