Re: Ultrium LTO2 & Performance?

Autor: Raphael H. Becker <Raphael.Becker_at_gmx.de>
Datum: 07.12.2006
Hallo Matthias,

On Thu, Dec 07, 2006 at 12:23:26PM +0100, Matthias.Toberer@consolut.de 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
>    Könnt Ihr mir Tips geben wie ich ein Backup am besten anstelle und
>    welches Tool dafür gut geeignet ist.

Bei der Größenordnung von Daten sollte man drauf achten, dass man die
richtigen Blöckgrößen verwendet.

Dafür eignet sich ein normales dd eigentlich ganz gut, das
herauszufinden:

Band einlegen 

1 GB linear mit dd schreiben, vorher jeweils zurückspulen 

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

   Für 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 dürfte. Wenn es bei größeren Werten für bs
keine Fehler gibt und auch kein Leistungseinbruch zu beobachten ist, 
dann kann man später auch meinetwegen bs=1M verwenden.
Evtl hängt dieser Idealwert auch noch von Kompressionseinstellungen ab.

Damit wäre mal die optimale Blockgröße zum Schreiben auf Band ermittelt
und damit auch die real maximal erreichbare Schreibgeschwindigkeit auf
Band (Kompression abschalten!).

Nun müssen die Daten "on the fly" aus dem Filesystem zusammengekratzt
werden. Diese liegen idR nicht schön 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 (früher war es so) vermeiden, dass der Datenstrom zum
Bandlaufwerk abreisst, d.h. "Buffer underrun" wie beim CD-brennen. Da
stoppt nämlich das Band und wird entweder ein Stück zurückgespult oder
es wird einfach eine Lücke im Band gelassen. Jedenfalls dauert es ewig,
bis sich die träge Bandmechanik da bewegt.

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

Mein Ansatz dafür ist es, zwischen Backup-Programm und Bandlaufwerk ein
Puffer einzuschieben. Im Falle von tar könnte das so aussehen:


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

Wieviel MB Buffer letztendlich sinnvoll verwendet, hängt von lokalen
Gegegenheiten ab, grundsätzlich erwarte ich aber schon durch einfaches
Einfügen von "buffer" ohne Parameter in diese Pipe einen
Performancegewinn.

Man kann sich das bildlich so bisschen wie "stop-and-go" im
Straßenverkehr vorstellen. "buffer" verhindert hier weitgehend, dass 
einer zB an einer Ampel anhalten muss, ohne buffer kommt auch immer nur
einer pro Grünphase durch). Ein ähnlich 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


Received on Thu Dec 7 17:34:53 2006

Dieses Archiv wurde generiert von hypermail 2.1.8.

Weitere Links: