• 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

OP
A

aerosol

Newbie
Ich hab mir nun mal das ganze LTO zeug durchgelesen:
http://www.usedlto.com/lto-neuigkeiten.0.html

und die scheinen diesen dingern ja auch sehr skeptisch gegenüber zu stehen. Scheint ebenfalls so, als bin ich nicht der einzige mit dem Problem, das ich das Band nicht ansatzweise füttern kann!

Ich habe nun nur ein Backup einer lokalen ~8GB Datei gemacht.

mit Arkeia = ca 12MB/s
mit:

Code:
tar -c -f - /tmp/speedtest/ | mbuffer -t -m 2000M -p 50 > /dev/st0
tar: Removing leading `/' from member names
warning: Blocksize should be a multiple of the blocksize of the output device (is 4096)!
This can cause problems with some device/OS combinations...
     0.0 kB/s in -  13306.8 kB/s out - 7667190 kB total - buffer   0% full
summary: 7674020 kB in 627.4 sec - 12231.9 kB/sec average

Obwohl der Buffer die ganze Zeit voll genug ist, schafft er von da zum Laufwerk nicht mehr als 12-13MB/s

Code:
warning: Blocksize should be a multiple of the blocksize of the output device (is 4096)!

was soll mir das sagen ?!



Alles nicht so einfach mit dem Backup :/

btw:
--------------------------------------------------------------------
Server:
--------------------------------------------------------------------
Prozessor: 2x Pentium III 1GHz
RAM: 2600MB
SCSI Controller: adaptec AHA-2940UW
HDD: HP Ultra320 universal hard drive
Filesystem: XFS
--------------------------------------------------------------------

CPU idle 95%!

Der SCSI-Controller müsste ja 40MB/s schaffen und das Bandluafwerk soll ja bis zu 1XXMB/s schaffen. Blos warum macht er definitiv nicht mehr als 13MB/s von
RAM über SCSI Controller auf Band?

Ich glaube ich komm dem ganzen langsam näher ;)
 
A

Anonymous

Gast
tar -c -f - /tmp/speedtest/ | mbuffer -t -m 2000M -p 50 > /dev/st0
tar: Removing leading `/' from member names
warning: Blocksize should be a multiple of the blocksize of the output device (is 4096)!
This can cause problems with some device/OS combinations...

Vermutung 1: mbuffer möchte gerne mit vielfachen von 4096 als Blockgröße haben. Da du bei tar keine Blockgröße angegeben hast, gilt dort default 20*512byte und das ist kein Vielfaches von 4096 :wink:

Vermutung 2:
Obwohl der Buffer die ganze Zeit voll genug ist, schafft er von da zum Laufwerk nicht mehr als 12-13MB/s
kann eine direkte Folge von Vermutung 1 sein. Das Laufwerk wird vom mbuffer mit Blöcken von 4096 Byte gefüttert, das macht die Performance jeden noch so potenten IO-Controllers in Verbindung mit Bandlaufwerken kaput, und verschleißt obendrein noch Band und Laufwerk.

Lade mal eine so bespielte Cartridge in das Laufwerk
mtst hattest du glaube ich installiert. mach mal bitte folgende Befehle als root natürlich, sonst haben wir keinen Zugriff auf das Device.

Code:
mtst -f /dev/nst0 rewind
mtst -f /dev/nst0 setblk 0
 for i in 1 2 3 4 5
  do 
  dd if=/dev/nst0 of=/tmp/block$i count=1 bs=131072
  mtst -f /dev/nst0 bsf 1 
  mtst -f /dev/nst0 fsr $i
done
Zur Erklärung: zurückspulen, im Laufwerk variable Blockgröße einstellen.
dann in einer Schleife eine 128KB-Block mit dd lesen und als Datei ablegen,
danach zurück zu Archivanfang und von dort aus wieder einen Block nach vorne positionieren.
sollte in etwa so eine Ausgabe machen. der IO-Error kommt daher, dass der Block auf dem Band kleiner ist als die 128 KB . Wir wählen in diesem Test immer eine größere Blockgröße aus, als wir auf dem Band vermuten, ( Obergrenze ist die konfigurierte maximale IO-Größe des Kontrollers, müssten 256KB sein) damit erhalten wir dann genau die Blockgröße die auf dem Band geschrieben steht.
Code:
0+1 records in
0+1 records out
/dev/nst0: Input/output error
0+1 records in
0+1 records out
/dev/nst0: Input/output error
0+1 records in
0+1 records out
/dev/nst0: Input/output error
0+1 records in
0+1 records out
/dev/nst0: Input/output error
0+1 records in
0+1 records out
/dev/nst0: Input/output error
jetzt kannst du dir mit ls die Blockgröße anschauen die auf das Band geschreiben wurden. Hier in meinem Beispiel sind es 64KB .
Code:
ls -l block*
-rw-r--r--  1 root root 65536 Jul 20 19:50 block1
-rw-r--r--  1 root root 65536 Jul 20 19:50 block2
-rw-r--r--  1 root root 65536 Jul 20 19:50 block3
-rw-r--r--  1 root root 65536 Jul 20 19:50 block4
-rw-r--r--  1 root root 65536 Jul 20 19:50 block5
Hiermit kannst du also feststellen mit welcher Blockgröße auf Dein Band geschreiben wird. Du brauchst für dieses Laufwerk minimum 128KB, sonst wurschtelt sich das Laufwerk zu tote und verschleißt übermaßig Band und Schreiblesekopf und Mechanik.
Server:
--------------------------------------------------------------------
Prozessor: 2x Pentium III 1GHz
RAM: 2600MB
SCSI Controller: adaptec AHA-2940UW
HDD: HP Ultra320 universal hard drive
Filesystem: XFS
--------------------------------------------------------------------
Dein SCSI-Kontroller ist ein bissel schwach auf der Brust für das Laufwerk, na ich hoffe die Platten hängen wenigsten an einem eigenen internen SCSI-Kontroller. Wenn du einen 64bit PCI-Bus hast, würde ich mich mal nach einem LVD-Ultra SCSI 160 oder 320 umschauen. Wenn du zufällig noch einen 66MHZ PCI-Steckplatz frei hast, dann bist dort wo du hin willst. Ab 100 Euro bist du beim Kontroller dabei. Dann kannst du auch das Kabel (bitte aber dann LVD-Kabel, hat andere Impedanzwerte) zur Jukebox auf bis ca. 15 Meter verwenden, und bist nicht auf den 1.5-2 Meter wie bei diesem jetzigen Kontroller angewiesen. Terminator sollte auch LVD-fähig sein, sollte aber sicher mit der Juke geliefert worden sein.

Der SCSI-Controller müsste ja 40MB/s schaffen
Das ist die theoretisch maximal zu erreichende Geschwindigkeit auf dem SCSI-Bus, bedeutet aber nicht, dass du die Daten auch permanet mit dieser Geschwindigkeit über den Bus treiben kannst. Mein Auto hat auch eine Höchstgeschwindigkeit von 190km/h aber wenn ich den Weg zur Arbeit plane, dann muss ich mit einer Durchschnittsgeschwindigkeit von 60km/h rechnen. :wink: :lol:

PS: Wenn die schreckliche Hitze in meiner Dachwohnung vorbei ist, dann werd ich mir mal hier einiges an Hardware aufbauen. Ich hab da einige Ideen wie man mit auch "kleiner Hardware" solche Leistungshungrige Laufwerke effektiv ansteuern kann, wird aber ein schönes Stück Programmierarbeit.

robi
 
OP
A

aerosol

Newbie
So erstmal danke für deine ganze Hilfe!!! :D

Habe mich so lange nich gemeldet, weil ich im urlaub war und vorher eine einigermassen akzeptabele lösung mittels synbak gefunden haben:

Code:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
             System: xxx
             Method: tape
             Option: 
               Type: local
             Source: /home/* /etc /usw
        Destination: /dev/st0
          Exclusion: 
     Synbak version: 1.0.3 - 20060520
  Technical support: 
       Backup begin: 2006/08/15 20:04:22 CEST
================================================================================
         Backing up: '/home/* /etc /usw' Size:[130.53 GB] Speed:[3.64 MB/Sec] Duration:[09:56:05] Status:[OK] 
--------------------------------------------------------------------------------
    Veryfing backup: 
Duration:[00:00:00] Status:[OK] 
--------------------------------------------------------------------------------
================================================================================
         Backup end: 2006/08/16 06:53:14 CEST
        Backup size: 130.53 GB
       Backup speed: 3.35 MB/Sec
        Source size: 129.62 GB
    Backup duration: 10:48:52
      Backup result: OK
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  Generating report: 'email' Duration:[00:00:00] Status:[OK] 
  Generating report: 'html'

naja gut was heisst akzeptabel... toll ist es nicht, aber es ist wenigstens ein Backup ;)

Ich habe nun mal die von dir geposteten Befehle ausgeführt um an die Blocksize zu kommen und das kam als Ergebnis bei dem synbak Backup heraus:

Code:
# ls -l /tmp/block*
-rw-r--r--  1 root root 131072 Aug 16 09:46 /tmp/block1
-rw-r--r--  1 root root 131072 Aug 16 09:46 /tmp/block2
-rw-r--r--  1 root root 131072 Aug 16 09:46 /tmp/block3
-rw-r--r--  1 root root 131072 Aug 16 09:46 /tmp/block4
-rw-r--r--  1 root root 131072 Aug 16 09:46 /tmp/block5

Laut der config Dateien arbeitet synbak mit:

Code:
backup_method_opts_default="--totals -b 256 -cf"

ich versuche mal mit diesem wert ein wenig rumzuspielen. Allerdings würde ich den Grund für die langsame durchschnittsgeschwindigkeit darin sehen, das es manchmal viele kleine dokumente sind, die es zu sichern gilt und ich den mbuffer erstmal aufgrund diverser fehlermeldungen aussen vor gelassen habe. Aber ohne den scheint es einfach nicht schneller gehen zu wollen, evtl muss ich nochmals mit dem rumprobieren.

Die Forderung des mbuffer nach einer Blocksize von min 4096, kann ich die erfüllen? wäre das sinnvoll? 4096*512/1024= 2048KB Blocksize oder meint der mbuffer sogar
8192*512/1024=4096KB?

Achja, wenn der buffer voll ist und die Geschwindigkeit nicht höher wird als ~16MB/s dann bleibt eigentlich nur der SCSI-Controlelr, der hint hinterherkommt oder?
 
A

Anonymous

Gast
3.35 MB/Sec ....toll ist es nicht, aber es ist wenigstens ein Backup
Da musst du dich schon noch mal mit beschäftigen, das werden ja wahnsinnige Sicherungszeiten, und wenn ein mögliches Recover oder das suchen auch nur einer Datei ähnliche Zeiten verursacht, kannst du schon mal die Hängematte für einen Notfall zurechtlegen.

Von diesem Sicherungstool habe ich noch nicht gehört, aber den Optionen nach, die du angegeben hast, scheint es auf tar aufzubauen.
Wenn du in meinem Testzeilen wirklich bei bs=...... meinen Wert und nicht etwa 1024 eingegeben hast, dann scheint da was nicht richtig zu funktionieren.

War das deine erste Sicherung, wenn du danach meine Befehlszeilen abgesetzt hast, dann ist es möglich, das das nächste Backup mit der richtgen Blocksize läuft.
Prüf einfach noch mal nach der nächsten Sicherung. Ansonsten such mal in der /var/log/messages mit grep "kernel" ob du irgendwas über st siehst. Normalerweise sollte er dort beim boot und oder beim Anlauf der Sicherung einen Eintrag machen, wenn er die Blocksize im Laufwerk setzt.

robi
 
OP
A

aerosol

Newbie
Von diesem Sicherungstool habe ich noch nicht gehört, aber den Optionen nach, die du angegeben hast, scheint es auf tar aufzubauen.

jop das arbeitet mit tar und hat noch nen paar nette features, wie zb das es ein html log-File erstellt, was ich sehr nett und übersuichtlich finde

Wenn du in meinem Testzeilen wirklich bei bs=...... meinen Wert und nicht etwa 1024 eingegeben hast, dann scheint da was nicht richtig zu funktionieren.

nein den wert habe ich geändert und es nun soweit auch hinbekommen, das er mit dem Blocksize draufschreibt, was ich ihm mit übergebe

z.B.:

Code:
tar --totals -b 8192 -c -f - /home/xxx | mbuffer -s 8388608 -t -m 1500M -p 75 > /dev/st0

Code:
mtst -f /dev/st0 setblk 0
 for i in 1 2 3 4 5
  do
  dd if=/dev/st0 of=/tmp/block$i count=1 bs=8388608
  mtst -f /dev/st0 bsf 1
  mtst -f /dev/st0 fsr $i
done

Code:
1+0 records in
1+0 records out
/dev/st0: Input/output error
1+0 records in
1+0 records out
/dev/st0: Input/output error
1+0 records in
1+0 records out
/dev/st0: Input/output error
1+0 records in
1+0 records out
/dev/st0: Input/output error
1+0 records in
1+0 records out
/dev/st0: Input/output error

Code:
# ls -l /tmp/block*
-rw-r--r--  1 root root 8388608 Aug 16 13:12 /tmp/block1
-rw-r--r--  1 root root 8388608 Aug 16 13:12 /tmp/block2
-rw-r--r--  1 root root 8388608 Aug 16 13:12 /tmp/block3
-rw-r--r--  1 root root 8388608 Aug 16 13:12 /tmp/block4
-rw-r--r--  1 root root 8388608 Aug 16 13:13 /tmp/block5


Allerdings kommt er ausm buffer mit höchsten 16MB/s aufs Band:

Code:
# tar --totals -b 8192 -c -f - /home/xxx | mbuffer -s 8388608 -t -m 1500M -p 75 > /dev/st0
tar: Removing leading `/' from member names
 16318.7 kB/s in -  16318.7 kB/s out - 884736 kB total - buffer  67% fullTotal bytes written: 1979711488 (1.8GB, 12MB/s)
     0.0 kB/s in -  16286.3 kB/s out - 1925120 kB total - buffer   1% full
summary: 1933312 kB in 213.9 sec - 9037.4 kB/sec average

Würdest du sagen, dass das nun am SCSI-Controller liegt?
 
A

Anonymous

Gast
Irgendwie habe ich das Gefühl du rennst von einem Extrem in das nächste, aber wenigstens gehts jetzt langsam vorwärts.

Jetzt sagst du tar es soll mit 4MB arbeiten und mbuffer soll mit 8MB arbeiten. Dein SCSI wird wahrscheinlich mit max. 256KB arbeiten also muss der SCSI-Treiber die 8MB in 32 Blöcke unterteilen und zum Laufwerk versenden, das Laufwerk muss erst alle 32 Blöcke erhalten bevor das Laufwerk damit etwas anfangen kann, und mit 8MB Blöcken im Laufwerk hebelst du eventuell die Hardwarekomprimierung im Laufwerk komplett aus.

Nimm mal vernünftige Werte für ein Bandlaufwerk also tar 256KB und mbuffer 256KB oder beide 128KB. Und probier das mal damit.
Wichtig auch mal den Spaß rückwärs versuchen, also das Band lesen und sich das Inhaltsverzeichniss ausgeben lassen. also tar -t
Hierbei wirst du dann auch wieder die Blockgröße einstellen müssen. Auch hier mal den Datendurchsatz messen.

robi
 
OP
A

aerosol

Newbie
jo bin wohl mal bisl durcheinander gekommen ;)

also damit alles mit 256KB löpt müsste das doch wie folgt aussehen oder?:

Code:
tar --totals -b 512 -c -f - /home/xxx | mbuffer -s 262144 -t -m 1500M -p 75 > /dev/st0


Weil:


Code:
# tar --help
Device blocking:
  -b, --blocking-factor=BLOCKS   BLOCKS x 512 bytes per record

beim tar: 512 Byte x 512 Byte = 262144 Byte = 256KB

##########################################################################################

Code:
# mbuffer --help 
-s <size>  : use block of <size> bytes for buffer (default 10240)

beim mbuffer: 262144 Byte = 256KB


Oder?


Das ganze hätte folgende Ausgaben:
Code:
# tar --totals -b 512 -c -f - /home/xxx | mbuffer -s 262144 -t -m 1500M -p 75 > /dev/st0
     0.0 kB/s in -      0.0 kB/s out - 0 kB total - buffer   0% fulltar: Removing leading `/' from member names
 21418.3 kB/s in -  17338.6 kB/s out - 815616 kB total - buffer  72% fullTotal bytes written: 1977876480 (1.8GB, 13MB/s)
     0.0 kB/s in -  18395.2 kB/s out - 1926656 kB total - buffer   0% full
summary: 1931520 kB in 201.8 sec - 9570.0 kB/sec average

Code:
# /root/blocksize_test
0+1 records in
0+1 records out
/dev/st0: Input/output error
0+1 records in
0+1 records out
/dev/st0: Input/output error
0+1 records in
0+1 records out
/dev/st0: Input/output error
0+1 records in
0+1 records out
/dev/st0: Input/output error
0+1 records in
0+1 records out
/dev/st0: Input/output error

Code:
# ls -l /tmp/block*
-rw-r--r--  1 root root 262144 Aug 16 14:19 /tmp/block1
-rw-r--r--  1 root root 262144 Aug 16 14:20 /tmp/block2
-rw-r--r--  1 root root 262144 Aug 16 14:20 /tmp/block3
-rw-r--r--  1 root root 262144 Aug 16 14:20 /tmp/block4
-rw-r--r--  1 root root 262144 Aug 16 14:20 /tmp/block5


So geht das Rücksichern mittels:

Code:
tar --blocking-factor=512 -xvf /dev/st0

auch problemlos!
 
A

Anonymous

Gast
Ich komme noch nicht so ganz klar mit den Ausgaben die mbuffer so liefert, wenn ich das so richtig interpretiere, dann schreibt tar sogar schneller in den Buffer, wie der Buffer die Datein aufs Band bringt.
Das würde dann wirklich auf den Kontroller deuten.
Aber das hatten wir ja schon festgestellt, das der etwas schwach auf der Brust ist. Kannst ja noch mal in den Logdateien vom boot oder dmesg nachschauen, wenn der Treiber vom Kontroller startet, dann sollte die Geschwindkeit gelogt werden, die zwischen Kontroller und Device ausgehandelt wird.
Aber wenn du mit dieser Geschwindigkeit erst mal sichern und recovern kannst, dann sollte dir erstmal ein Stück weitergeholfen sein. Versuch jetzt mal dein BackupTool so hinzubekommen und lass jetzt einfach mal eine komplette Sicherung laufen.
Was macht eigentlich das Anfangsproblem, dass die Bänder nicht voll geschrieben werden?


robi
 
OP
A

aerosol

Newbie
Das Problem, das die Bänder nicht voll geschrieben werden ist shcon lange behoben(erwähnte ich das nicht? :oops: ).

Und das mit der mbuffer Ausgabe siehst du richtig und somit habe ichs nun auch auf den Controller abgeshen ;)

Allerdings wären diese ~16MB/s für die Sicherung ja shconmal was...

Ich habe nun mal zum testen alle home directories zum sichern angeschmissen (ca. 23GB) und da der mbuffer ja direkt live die Daten liefert, ist mir jetzt eine weitere Fehlerquelle aufgefallen, warum ich nicht mindestens die 16MB/s hinbekomme und zwar:

Wenn ich dem mbuffer mitgebe, das er z.B. erst anfangen soll Daten aufs Band zu schieben, wenn der 2GB Buffer (es sind ja "nur" 2,5 GB Ram zur Verfügung) zu 75% gefüllt ist, läuft das am Anfang auch recht ansehnlich. Aber da viele Home directoreis aus vielen kleinen Dateien bestehen und er mit konstant 16MB/s aufs Band schreibt, kommt es ziemlich schnell zu der Situation, dass der Puffer nicht schnell genug "nachgefüllt" wird und somit wieder auf 0 % läuft, das Band stoppt und wieder gewartet wird, bis Der Puffer wieder bei 75% ist. Da streicht natürlich einige Zeit ins Land... :/

Wenn ich mir jetzt die Ausgabe von

Code:
# mbuffer --help
usage: mbuffer [Options]
Options:
-b <num>   : use <num> blocks for buffer (default 256)
-s <size>  : use block of <size> bytes for buffer (default 10240)
-m <size>  : use buffer of a total of <size> bytes
-L         : lock buffer in memory (unusable with file based buffers)
-P <num>   : start writing after buffer has been filled more than <num>%
-p <num>   : start reading after buffer has been filled less than <num>%
-i <file>  : use <file> for input
-o <file>  : use <file> for output
-I <h>:<p> : use network port <port> as input, allow only host <h> to connect
-I <p>     : use network port <port> as input
-O <h>:<p> : output data to host <h> and port <p>
-n <num>   : <num> volumes for input
-t         : use memory mapped temporary file (for huge buffer)
-T <file>  : as -t but uses <file> as buffer
-l <file>  : use <file> for logging messages
-u <num>   : pause <num> milliseconds after each write
-r <rate>  : limit read rate to <rate> B/s, where <rate> can be given in k,M,G
-R <rate>  : same as -r for writing; use eiter one, if your tape is too fast
-f         : overwrite existing files
-a <time>  : autoloader which needs <time> seconds to reload
-A <cmd>   : issue command <cmd> to request new volume
-v <level> : set verbose level to <level> (valid values are 0..5)
-q         : quiet - do not display the status on stderr
-c         : write with synchronous data integrity support
-H
--md5      : generate md5 hash of transfered data
-V
--version  : print version information
Unsupported buffer options: -t -Z -B

anschaue, gibt es die Möglichkeit ( -T <file> : as -t but uses <file> as buffer ) zu nutzen. Das ist soweit ich das verstanden hab ein Bufferfile, was auf der HDD leigt und somit größer sein kann. Somit könnte ich die Buffersize auf zb 10GB stellen und hätte genug Zeit aus dem Buffer zu schreiben und ihn parallel "nachzufüllen". Allerdings ignoriert mbuffer idese Option und schreibt weiterhin ins RAM bzw kommt mit der Fehlermeldung, das keien 10GB im Ram verfügbar sind :(
 
A

Anonymous

Gast
Wenn ich dem mbuffer mitgebe, das er z.B. erst anfangen soll Daten aufs Band zu schieben, wenn der 2GB Buffer (es sind ja "nur" 2,5 GB Ram zur Verfügung) zu 75% gefüllt ist, läuft das am Anfang auch recht ansehnlich. Aber da viele Home directoreis aus vielen kleinen Dateien bestehen und er mit konstant 16MB/s aufs Band schreibt, kommt es ziemlich schnell zu der Situation, dass der Puffer nicht schnell genug "nachgefüllt" wird und somit wieder auf 0 % läuft, das Band stoppt und wieder gewartet wird, bis Der Puffer wieder bei 75% ist. Da streicht natürlich einige Zeit ins Land... :/

Genau das ist ja der Witz an dem Buffer, er soll solange die Daten kommen auch kontinuierlich Daten an das LW liefern können. Und wenn die Daten zu langsam kommen, dann soll er das LW geziehlt anhalten bis der Buffer wieder gefüllt ist damit wieder konitnuierlich Daten geliefert werden können. Das soll verhindern, das das Laufwerk ständig angehalten und wieder gestartet wird, setzt aber vorraus, dass du auch über SCSI genügend Daten rüberschaffen kannst, damit das Laufwerk auch wirklich nicht anhalten braucht, weil immer genug Daten da sind.
Das ist bei dir im Moment noch nicht der Fall, aber dieser Buffer sorgt jetzt schon mal für eine Besserung, und wenn du Rechner übers Netz sicherst, dann macht es auch jetzt schon wirklich Sinn. Ich würde mal sagen du kannst aber bequem auf 95% gehen zum starten 75% scheinen mir zu wenig. Auch die Größe von 2GB halte ich für übertrieben, oder soll der Rechner wirklich nur sichern und nichts anderes machen.
Eine Auslagerung auf einen Plattencache macht nur Sinn, wenn die Daten wirklich übers Netz viel zu langsam sind, oder du von sehr langsamen Devices (sehr langsame Festplatten oder andere externe Geräte) sichern wolltest, dann kannst du den Cache auf einer schnellen Platte anlegen, mußt aber bedenken, auf diese Platte wird geschrieben und gelesen zur selben Zeit, also die Geschwindigkeit deiner Platte kann vom Cache nur ca. zur Hälfte genutzt werden.

robi
 
OP
A

aerosol

Newbie
also der Rechner soll Nachts nichts anderes machen als sichern. Ich habs auch shcon mit 95% versucht, wenn er dann allerdings bei 95% angekommen ist, schreibt er mit 16MB/s kontinurierlich aufs Band.

Bis hierhin gut :)

ABER da, wie beschrieben, es sich hier teilweise um sehr viele kleinen Files und damit verbunden auch sehr viele Ordnerwechsel handelt, kommt er halt einfach nicht dazu den buffer nachzufüllen und er kommt ziemlich schnell auf 0% Füllung.

d.h. Das Band stoppt und wartet ein paar Minuten, bis der Buffer wieder bei 95% angekommen ist. Ich finde das ganze so noch nicht so glücklich :/
 
OP
A

aerosol

Newbie
So das Backup habe ich heute Nacht mal mit dem eingebautem mbuffer durchlaufen lassen mit dem Ergebnis:

Code:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
             System: xxx
             Method: tape
             Option: 
               Type: local
             Source: /home/*
        Destination: /dev/st0
          Exclusion: 
        Synbak host: xxx
     Synbak version: 1.0.6 - 20060729
  Technical support: 
       Backup begin: 2006/08/16 20:04:30 CEST
================================================================================
         Backing up: '/home/*
Size:[130.41 GB] Speed:[5.15 MB/Sec] Duration:[07:01:36] Status:[OK] 
--------------------------------------------------------------------------------
================================================================================
         Backup end: 2006/08/17 03:59:29 CEST
        Backup size: 130.41 GB
       Backup speed: 4.57 MB/Sec
        Source size: 129.53 GB
    Backup duration: 07:54:59
      Backup result: OK
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  Generating report: 'email' Duration:[00:00:00] Status:[OK] 
  Generating report: 'html'

Also es ist durchgelaufen nur wie befürchtet, reichen die 2 GB Puffer leider nicht :(
 
A

Anonymous

Gast
Also das sind jetzt erst mal 3 Stunden die gewonnen sind.
Die Geschwindigkeit die du angezeigt bekommst, ist natürlich die Gesamtgeschwindigkeit, und da sind die Schreibpausen schon alle mit eingerechnet.
Ich nehme mal an, du hast jetzt bei der Sicherung genau die selben Parameter wie gestern bei den Tests verwendet.
Wir haben ja gesehen, du kannst mit deinem Kontroller mit 16MB/s aus dem Speicher auf das Band schreiben, da sollten deine 2GB Cache so ca. für 2-3 Minuten reichen, um das Band in Bewegung zu halten, und versuchen das Laufwerk in einem einigermaßen akzeptabelen Arbeitsbereich zu versetzten.
Aber bei dieser Geschwindigkeit ist da aber wohl noch ein anderes Problem, wo kommen denn die Daten auf /home/* her, ist das eine Platte oder ist das eine share oder was ist das? Oder was ist in den Unterordnern noch irgendwas gemountet? Scheinbar gibt es dort irgendwelche Performanceprobleme beim sequentiellen runterlesen der Daten.


robi
 
OP
A

aerosol

Newbie
das stimtm natürlich! 3 Std sind gewonen und das Band arbeitet Phasenweise ordentlich dann kann es sich wieder lange erholen ;)

Die Daten kommen fast alle ausschliesslich von einem gemounteten NFS-share welcher auf einem NetApp FAS270 liegt.

Frage nun:

Ist die Verbindung zum Filer zu langsam oder ist wird die Verbindung von den ganzen Ordnerwechslen nur ausgebremst?



edit:

Also ich habe jetzt mal eine ~8gb Große Datei mit dem "mc" rüberkopiert

vom Backup Server auf den Filer mit mindestens: 25MB/s

vom Filer auf den Backup Server mit midestens: 23MB/s
################################################################################################

Da es alelrdings eine gigabit Verbindung ist, sollte diese Zahl schon höher sein, oder? Es sei denn die Platten schaffen nicht mehr...



Somit würde ich nun behaupten, das ihm die ganzen Ordnerwechsel und kopieren der kleinen Dateien den Speed nimmt... nur wie bekomme ich das behoben ...?
 
A

Anonymous

Gast
Der Netapp Filer kann es erst mal primär nicht sein, der hat genügend Power, vorausgesetzt er ist ordentlich konfiguriert, wovon ich aber ausgehe, auch sollte dieser eine GBit LAN Verbindung zu deinem Backupserver haben, da sollte auch bedeutend mehr durchkommen. Ich tippe da ehr auf das NFS.
Nachts wenn das Backup läuft wird wohl nicht die Masse dort los sein, vermute ich mal.

Eventuell sind die Mount Optionen ungünstig. Stichwort sync/async
Aber von solchen Netz und Share Problemen habe ich wenig Ahnung, bin immer froh, wenn ich meine Filesysteme zwischen den paar Rechner in meinem Homenetz einigermaßen ohne fremde Hilfe zusammenkonfigurieren kann. :lol:

Versuch mal dort ein paar mehr Informationen durch irgendwelche Tests oder so rauszufinden, und dann eine neues Thema bei den Fileservern hier im Forum aufzumachen, da tummeln sich unsere Netz und Share Profis. Bei der Überschrift von diesem Thema hier, kommen die nicht vorbei geschaut :wink:

robi
 
OP
A

aerosol

Newbie
Ok den part versuche ich nun mal da rauszubekommen ;)

VIELEN DANK FÜR DEIN EBISHERIGE HILFE!!! :)

ich werde mich dann ma melden, aber sind j ashcon einiges voran gekommen :)
 
A

Anonymous

Gast
Ich hab mir jetzt mal einen Versuchsaufbau mit ähnlichem Server hingestellt und ein LTO2 LW drangehängt. Ja und mbuffer hab ich nun auch mal installiert und getestet. Da ich einen SCSI LVD U160 Kontroller verwende konnte ich über mbuffer bis 60MB/s und mehr sichern. :lol:
Werde mir wohl jetzt ernsthaft überlegen, meine Sicherungen alle auf mbuffer und die schnellen Laufwerke umzustellen. :wink:
Die Optionen die wir zusammen für tar mbuffer und LTO erstellt haben, und mit denen du die letzten Tests gemacht hast, sind alle richtig und funktionieren gut.

Über einen LinuxPC habe ich ein nfs Verzeichnis readonly freigegeben. Allerdings ich habe nur ein 100 Netz. Normale Dateien konnte ich über tar konstant mit 8-11MB/s in mbuffer einlesen und wenn der mbuffer gefüllt war mit bis 60MB/s auf LTO2 schreiben. ( habe 1,5 GB von 2GB Speicher als Buffer verwendet)
Dann habe ich mir auf dem nfs-Server ein böses Verzeichnis angelegt. Habe dazu folgendes Script zum Anlegen verwendet.
Code:
#!/bin/bash

function rekursion () {
typeset -i ZAHL
ZAHL=$1
 if [ $ZAHL == 4 ]
   then
   for i in 1 2 3 4 5 6 7 8 9 0 
     do
     echo "asdfasdfasdfasdfasdfasdfasdfasdfafdafdfdsafdsafdsafdsa" > $i
   done
 else
  for i in 1 2 3 4 5 6 7 8 9 0 A B C D 
   do
   mkdir $i
   cd $i
   LAUF=$ZAHL+1
   rekursion $LAUF
   cd ..
  done 
 fi }
rekursion 0
Das braucht ein paar Minuten und ergibt
du -sk testdir
1536640 testdir
find testdir | wc -l
425531
und als tar ohne Kompression gepackt 414711808 Byte

jetzt der Versuch das über nfs auf dem Sicherungsserver mit den selben Parametern zu sichern, ergab konstant ca. 500kB/s als Eingabe in mbuffer.

Als Test: auf dem nfs-Server mit tar gepackt und auf eine andere Platte geschrieben.
Gesamtzahl geschriebener Bytes: 414711808 (395MB, 5.9MB/s) (auf reiserfs)
Gesamtzahl geschriebener Bytes: 414711808 (395MB, 855kB/s) (auf ext2)
Als Test: zum Vergleich Bilder auf ext2 mit tar gepackt
Gesamtzahl geschriebener Bytes: 389021696 (371MB, 11MB/s)
Aber egal ob ich das Verzeichnis auf ext2 oder das auf reiserfs versucht habe auf dem anderem Server über nfs zu sichern, ich kam nie über die 500kb/s aber die sehr konstant.

Jetzt ziehe selbst eine Schlussfolgerungen.:wink
Ich denke, der Einsatz und die Optionen von mbuffer sind jedenfalls genau das Richtige für dich

robi
 
OP
A

aerosol

Newbie
Guten morgen...

hmm weiss nun nich, ob ich über dein Ergebnis froh sein soll oder nich ;)

Ich habe das nun richtig verstanden, das du, genau wie ich, beim sichern vieler kleiner verschachtelter Ordner nicht auf eine ordentliche Geschwindigkeit kommt!? Würde heissen, das ich damit wohl nun leider leben muss... Aber ein neuer SCSI Controller scheint evtl angebracht zu sein :)

Achja, welche NFS Version nutzt du? mein kernel hat nur NFS V3 support mit kompiliert. bei meinem 10.1 gibt es alelrdings schon die Version 4 Experimentell. Hast du diese Option auch aktiviert gehabt? Oder wäre das evtl noch einen Versuch wert?
 
A

Anonymous

Gast
aerosol schrieb:
Achja, welche NFS Version nutzt du? mein kernel hat nur NFS V3 support mit kompiliert. bei meinem 10.1 gibt es alelrdings schon die Version 4 Experimentell. Hast du diese Option auch aktiviert gehabt? Oder wäre das evtl noch einen Versuch wert?

Mmmm. Erwischt. Ach da gibts wohl verschiedene Versionen ?:oops:
Ehrlich gesagt :?: :?: :?: hab von NFS fast überhaupt keine Ahnung.
NFS Server SuSE 9.1 --> NFS-Client SuSE 10.1
kann mich nicht erinnern irgendwo Optionen zwecks erzwingen einer bestimmten Version gesetzt zu haben.

robi
 
OP
A

aerosol

Newbie
scheint aber auch mit der Version meines 10.1 Clients ( Es waren sowohl die Module NFS-Client V3 und V4(experimental) aktiviert) nichts gebracht zu haben... :(

Also somit ein NFS bzw. allgemeinses Datentrasfer "problem"? OK es ist für mich verständlich, das der Transfer eines Großen Files schneller geht, als die gleich größe aufgeteilt in X Unterordner, die erst noch durchsucht werden müssen...

Kann man die NFS-gesharten Dateien evtl auch andersweitig lesen (irgendwie "dümmer"), so dass er nicht die Ordner durchsucht, sondern eine Art Abbild macht!? Weil hier so natürlcih Zeit und Leistung verschenkt wird!
 
Oben