Re: Ultrium LTO2 & Performance?

["Raphael H. Becker" <Raphael.Becker@xxxxxx>]

Hallo Matthias,

On Thu, Dec 07, 2006 at 12:23:26PM +0100, Matthias.Toberer@xxxxxxxxxxx wrote:
>    Hallo Liste,
>    ich habe aktuell einen PowerEdge mit einem Ultrium LTO2 Bandlaufwerk.
>    OS ist SLES10. Um Daten auf das Band zu schieben habe ich jetzt
>    verschieden Tools getestet, wie .z.B tar cpio und taper. Aber die
>    Geschwindigkeit ist mit ca. 137MB/min wirklich nicht berauschend wenn
>    die Spezificationen von 130/MB/s reden.

130MB/sec als Schreibgeschwindigkeit auf das Medium oder die
Geschwindigkeit der Schnittstelle am PC?

>    Zu sichern sind ca 250GB an Daten
>    Koennt Ihr mir Tips geben wie ich ein Backup am besten anstelle und
>    welches Tool dafuer gut geeignet ist.

Bei der Groessenordnung von Daten sollte man drauf achten, dass man die
richtigen Bloeckgroessen verwendet.

Dafuer eignet sich ein normales dd eigentlich ganz gut, das
herauszufinden:

Band einlegen 

1 GB linear mit dd schreiben, vorher jeweils zurueckspulen 

   dd if=/dev/zero of=/dev/bandlaufwerkdevicename bs=64k count=16384

   Fuer alle Wertepaare bs*count:
   32k*32768
   64k*16384
   128k*8192
   256k*4096
   512k*2048
   1024k*1024
   ...

Ich vermute, dass entweder bei 64k*16384 oder bei 128k*8192 das Maximum
an Durchsatz erreicht sein duerfte. Wenn es bei groesseren Werten fuer bs
keine Fehler gibt und auch kein Leistungseinbruch zu beobachten ist, 
dann kann man spaeter auch meinetwegen bs=1M verwenden.
Evtl haengt dieser Idealwert auch noch von Kompressionseinstellungen ab.

Damit waere mal die optimale Blockgroesse zum Schreiben auf Band ermittelt
und damit auch die real maximal erreichbare Schreibgeschwindigkeit auf
Band (Kompression abschalten!).

Nun muessen die Daten "on the fly" aus dem Filesystem zusammengekratzt
werden. Diese liegen idR nicht schoen hintereinander auf der Platte. Wenn
die Platte. Bei gemischten Daten schwankt das deutlich zwicshen 1MB/sec
und 50MB/sec von normalen RAIDs 

Nun muss man (frueher war es so) vermeiden, dass der Datenstrom zum
Bandlaufwerk abreisst, d.h. "Buffer underrun" wie beim CD-brennen. Da
stoppt naemlich das Band und wird entweder ein Stueck zurueckgespult oder
es wird einfach eine Luecke im Band gelassen. Jedenfalls dauert es ewig,
bis sich die traege Bandmechanik da bewegt.

Nutzt man "tar" oder "cpio" ohne weiteres, dann wird immer nur ein
Haeppchen aus dem Filesystem gelesen und ein Haeppchen auf Band
geschrieben. Der eine Teil wartet (worst case) immer auf den anderen
Teil, ziemlich schlecht, denn beides koennte parallel laufen.

Mein Ansatz dafuer ist es, zwischen Backup-Programm und Bandlaufwerk ein
Puffer einzuschieben. Im Falle von tar koennte das so aussehen:


(cd / && tar cvf - data/ ) | buffer -m 10m | dd of=/dev/bandlaufwerk obs=128k 

Wieviel MB Buffer letztendlich sinnvoll verwendet, haengt von lokalen
Gegegenheiten ab, grundsaetzlich erwarte ich aber schon durch einfaches
Einfuegen von "buffer" ohne Parameter in diese Pipe einen
Performancegewinn.

Man kann sich das bildlich so bisschen wie "stop-and-go" im
Strassenverkehr vorstellen. "buffer" verhindert hier weitgehend, dass 
einer zB an einer Ampel anhalten muss, ohne buffer kommt auch immer nur
einer pro Gruenphase durch). Ein aehnlich wie buffer arbeitenedes Programm
heisst "team" und arbeitet mit 4 geforkten Prozessen, die sich im Kreis
drehen, also bildlich ein Kreisel. Nicht schnell, aber niemand muss
(idealerweise) anhalten, der ganze Verkehrsfluss ist "elastischer". 

MfG
-- 
Raphael Becker                                    http://rabe.uugrn.org/
                      http://schnitzelmitkartoffelsalat.und.rahmspin.at/
.........|.........|.........|.........|.........|.........|.........|..



-- 
http://mailman.uugrn.org/mailman/listinfo/uugrn