/dev/Null-Tape um Lesegeschwindigkeit Dateisystem zu messen

Ich habe Probleme mit den Backups: Meine Dateisysteme scheinen nicht genug Lesegeschwindigkeit zu leisten, denn mein LTO1 Laufwerk wird kurz nach dem Start eines Backsups immer langsamer und fängt dann mit dem ShoeShining an.
Ich mache jetzt Tests mit tar und damit ist der Effekt ebenfalls sichtbar. Messe ich mittels iotop den Durchsatz bei den Sicherungen, so sind es meist nur 3 bis 5MB/s mit Spitzen nach oben mal von 25MB/s aber auch mal nur 2MB/s.
Normale Kopieraktionen von Platte zu Platte sind meist 50MB/Sekunde; HDPARM wirft auch für jede einzelne Platte genug Speed aus (70MB/s):

Konfiguration:
Noname Server mit AMD Phenom, 4Kerne, 3GHz, 8GB RAM; opensuse 11.3 x64
Platten:
2x 500GB Sata an PCI 3Ware 2-Kanal SATA-Raid-Controller (Raid-1)
2x 500GB SATA an Motherboard S-ATA Anschlüssen (mittel mdadm als Raid 1)
1x 1000GB Sata an Motherboard S-ATA Anschluß (BOD Konfiguration)

Dateisysteme: Ext4 auf LVM allen Partitionen

Um mal verschiedene Konfigurationen von Platten,Kanälen, Anschlüssen zu vermessen etc. suche ich eine Art Tape-Null Device.
Ein "tar -cvf /dev/null /home/" wird zwar syntaktisch angenommen, aber führt überhaupt keine Leseversuche durch (Speed über ein Verzeichnis mit ISO Dateien: 0,387 Sekunden für 108GB; das ist wohl kaum durch die SATA Leitung gegangen)
Hat jemand einen Tip, wie ich ein tar auf ein Null-Device ausführen kann oder sonst irgendwie die Lese-Geschwindgkeit meines Dateisystem prüfen kann, ohne ein Device, wo die Daten hingeschrieben werden (denn das verzerrt meine Messungen der lesenden Plattenkanäle)?

Hallo,

du kannst dir mit dd nen 5 Gig große Testdatei erstellen lassen und diese dann nach /dev/null "zurück schieben"
time dd if=/dev/zero of=zerofile.test bs=1k count=5000000
time dd if=zerofile.test of=/dev/null bs=1k

natürlich solltest du erst in der Konsole dahin navigieren wo du lese/schreib Rechte hast und wo Platz ist.

Grüße Beppo

sowas habe ich schon gemacht. Danach sieht alles gut aus.
Ich habe das eben trotzdem noch mal auf meinem System laufen lassen.
Danach ist alles gut:
part1 raid1 set (virtualbox): Write 64s; 79,7mb/s; Read 67s; 75mb/s
part2 bod sata (div. Backups): Write 57s; 88,9mb/s; Read 61s; 82,9mb/s
part3 3ware sata (arbeits-Volume, LVM): Write 215,36s; 23,8MB/s; Read 118s; 43,5MB/s
part4 3ware sata gleiche disk wie part3(root): Write 222s; 23,1MB/s; Read 87s; 58,8MB/s

Okay part3 und part4 liegen auf dem raid1 array am 3ware controller. Der steckt nur im PCI Slot, was vielleicht etwas bremst. Der Speed auf dem Array is deutlich langsamer als bei den Platten direkt an den Motherboard SATA Anschlüssen. Trotzdem sollte der Speed locker ausreichen um 15 bis 20MB/s zu liefern die ich für einen flotten Backup brauche.
Nur irgendwie im Dateimix beim Sichern (Bacula oder tar) bricht der Transfer ein. Laut iotop nur wenige MB/s.
Bei obigen Tests habe ich iotop mal mitlaufen lassen und dort kriege ich Durchsatzraten angezeigt, die dann dem Ergebnis des dd entsprechen.
Wenn ich mal ein tar irgendwo hinschieben könnte. Eine RAM disk wäre eine option. Vielleicht zwacke ich da mal 1 oder 2GB für ab und versuche dann mal ein tar da hinein.

So und dann habe ich noch mal ein tar in eine Ramdisk versucht und auf eine einzelne SATA Platte (/etc und ein kleines home Verzeichnis = 700MB)
Vorher immer schon den Cache geleert, sonst dauern kommen die Daten beim 2. Lauf nur noch aus dem Cache
(sync; echo 3 > /proc/sys/vm/drop_caches)
In eine Ramdisk=29,5s -> 23,7MB/s; iotop zeigt stark wechselnde Transferraten, meist aber deutlich über 25MB/s
auf die separate Platte:; 30,5s; also ziemlich die gleiche Geschwindigkeit.

Demnach scheint der Lesezugriff doch in Ordnung zu sein.

Dann werde ich als nächstes mal den LTO streamer vermessen.

Eine RAM- Disk liegt im RAM und ist immer schneller als ein Bandlaufwerk und kann daher nicht zum Vergleich verwendet werden.

Ja das ist logisch. Es geht darum die Daten so schnell wie möglich zu lesen. Nur wohin damit? /dev/null funktioniert nicht, also ist die Ramdisk die am einfachsten und schnellsten verwendbare Alternative.
Das Resultat ist also: Die Lesegeschwindigkeit sollte doch okay sein.
Dann muss ich jetzt mal die reine Schreibe-Seite zum Tape untersuchen (z.B. eine 5GB Testdatei einmal aus dev/random und eine andere aus /dev/zero füllen).
Da die null-Datei in der HW-Compression des Tapes super komprimiert wird, sollte die Geschwindigkeit hier nur durch den Transfer PCI-Bus/SCSI-Kanal und Tape Hardware begrenzt sein. Der Max-Wert hier sollte die maximale Schreibgeschwindigkeit angeben, welche die Hardware zum Tape transportieren kann.
Wenn ich die Random-Datei sichere, dann muss das Tape die Daten 1:1 aufzeichnen. Das sollte mir die max. Schreibgeschwindigkeit des gesamten Systems PCI-SCSI-Tape-Band aufzeigen.
Das werde ich vielleicht am Wochenende mal antesten. Vielleicht zeigt mit iotop dann auch die jeweils aktuelle Schreibrate an.

Auch die Ausführungen von robi (und gegebenenfalls seinen Linupedia-Beitrag) solltest Du in Deine Überlegungen mit einbeziehen.

Interessanter Link! Vielen Dank, das werde ich mir auch mal anschauen.