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

[gelöst] LTO-4 fängt an zu wienern ("shoeshining")

K

kaix.sh

Newbie
Hallo zusammen,

ich möchte von einigen Ordnern auf eine 2 TB-Partition ein Backup auf ein LTO-4-Band machen. Der Streamer ist über SAS angeschlossen (PCIe-Controller von Atto) und die Festplatten der Quelldaten liegen in einem Hardware-RAID5 an einem 3ware-PCIe-Controller.
Wenn ich
Code: 
tar cfv /dev/tape /daten/backupdateien
eingebe, passiert zwar etwas, aber nicht das, was ich will.
tar gibt brav die gerade verarbeitete Datei aus, aber das Bandlaufwerk fängt an zu wienern ("shoeshining"), läuft also immer wieder an und stoppt wieder.
Da dieses Verhalten weder für das Band noch für das Laufwerk von Vorteil ist, möchte ich das vermeiden. Außerdem würde sich das Backup dadurch vermutlich Tage hinziehen.
Zugriffe auf das Hardware-RAID erfolgen nur sehr sporadisch, d.h. es kann eigentlich nicht daran liegen, dass die Platten zuwenig Daten liefern.
Vielleicht ist das ein Problem der Pufferung?
Code: 
backupserver:/ # hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads:   2014 MB in  2.00 seconds = 1007.45 MB/sec
 Timing buffered disk reads:  368 MB in  3.01 seconds = 122.30 MB/sec

Das sollte eigentlich reichen, zumal ja bei einem HDD-Flaschenhals zumindest permanenter Zugriff auf die Festplatten stattfinden sollte, oder?

Ich habe mich schon nach anderen Backup-Lösungen umgeschaut, mit folgenden Ergebnissen:
Kdat: Kann nur Medien bis max 99 GB benutzen.
Arkeia: Sehr umständlich, viel zu mächtig und vor allem: schlechtes Interface. Wurde zwar inzwischen auf Browser umgestellt, ist aber nach wie vor eher war für diejenigen, die es Programmiert haben. Keine oder unklare Fehlermeldungen.


Wer kann mir evtl. noch eine andere Software empfehlen?
Wie kann ich die Geschwindigkeit des Streamers testen?
Gibt es eine Möglichkeit, festzustellen, warum bzw. wann der Streamer zwischendurch stoppt?

Vielen Dank und viele Grüße

Kai
 
A

Anonymous

Gast
http://wiki.linux-club.de/opensuse/Bandlaufwerke_und_LINUX#Pufferung_der_Daten_zwischen_Laufwerk_und_LINUX

am besten mal den ganzen Artikel überfliegen, du hast auch das Blocksizeproblem.

Robi
 
OP
K

kaix.sh

Newbie
Dankeschön! (btw: schöner Artikel!)

Code: 
[x] Artikel > /dev/brain

Ich gehe also jetzt davon aus, dass ich mbuffer brauche (und erstmal für 64bit kompilieren muss - *schluck*).
Werde ich gleich mal ausprobieren!
 
A

Anonymous

Gast
+ Befehl Variable Blockgröße an Laufwerk senden
und dann immer bei allen Sicherungen und Leseaktionen mit 256KB Blocksize arbeiten.

robi
 
A

Anonymous

Gast
jengelh schrieb:
Wieso mbuffer, wenn es bei tar doch die Option -b gibt. (In der Hoffnung dass die das nötige tut.)
Zum Vergrößern anklicken....

Es müssen uU. 1GB -2 GB an Datenblöcken (welche zB mit tar -... -b 512 ..... erstellt/verarbeitet werden) im Speicher in einer Art Pipe zwischengebuffert werden. Damit werden die Geschwindigkeitsdiffernzen von Laufwerk einerseits und Backupsoftware inclusive Filesystemzugriffe gebuffert. Die Backupsoftware und das Laufwerk müssen absolut unabhängig mit ihren ureigenen Daten-Geschwindigkeiten mit dieser Bufferpipe arbeiten können, erst definierbare High- und Low-Marks blockieren vorübergehend eine der beiden Seiten dieser Pipe. Sowas ist für den Betrieb solcher Laufwerke nicht nur ratsam sondern eine von wenigen Möglichkeit die Laufwerke an normalen Servern unter den vom Hersteller vorgesehenen optimalen Parametern zu betreiben. Siehe auch Link oben, da ist das Prinzip genauer erklärt. Übrigens fertige Pakete sollte bei den Utilities bei openSUSE zu finden sein.

robi
 
OP
K

kaix.sh

Newbie
Soo, nachdem ich festgestellt habe, dass man mit 2GB RAM keinen 4GB Puffer verwenden kann :lol:
ergibt sich folgendes:
Code: 
backupserver:/daten/video # tar -cl -b 512 -f ./ 2>/dev/null | /usr/local/bin/mbuffer -L -s 256k -m 1G -P 85 > /dev/nst0
summary:  0.0 kByte in 0.5 sec - average of  0.0 kB/s, 1x empty
in @  0.0 kB/s, out @  0.0 kB/s,  0.0 kB total, buffer   0% full
summary:  0.0 kByte in 0.5 sec - average of  0.0 kB/s, 1x empty
backupserver:/daten/video #

Ich habe dann mal die Fehlerausgabe von tar in eine Datei umgeleitet, dort sagt man mir freundlich
Code: 
tar: Cowardly refusing to create an empty archive
Try `tar --help' or `tar --usage' for more information.

So, jetzt frage ich mich, was ich noch falsch mache... :(
 
T

Tooltime

Advanced Hacker
Ich habe zwar keine große Ahnung von dem Thema, aber ich schätze du warst zu hektisch. Die tar-Option "-f ./", speichere das Backup in den Namen des aktuellen Arbeitsverzeichnis ergibt keinen Sinn. Sollte wohl ein "-f- ./"werden.
 
OP
K

kaix.sh

Newbie
Tatsache, da fehlte mit ein Strich...
Jetzt passiert zwar etwas, allerdings genau dasselbe wie vorher ohne mbuffer. Ich habe offenbar noch ein anderes Problem.
(Dem Streamer habe ich vorher
Code: 
mtst -f /dev/nst0 setblk 0
geschickt.)
mbuffer zeigt mit aber permanent 100% Füllstand an. Nach einigen Minuten gewiener komme ich dann auf sagenhafte 17 MB/s.
Code: 
backupserver:/daten/video # tar -cl -b 512 -f- ./ 2>/tmp/tarpip.log | /usr/local/bin/mbuffer -L -s 256k -m 1G -P 85 > /dev/nst0
in @  0.0 kB/s, out @  0.0 kB/s, 6944 MB total, buffer 100% full
summary: 6944 MByte in  6 min 32.1 sec - average of 17.7 MB/s, 1x empty

Ich würde außerdem tar gerne mit -v nutzen und die Ausgabe in eine Logdatei in /tmp/tarstream.log schreiben. Wie muss ich den Befehl so ergänzen, dass das klappt? Und was kann ich noch ausprobieren, damit das Sichern an sich klappt?

TIA

Kai
 
A

Anonymous

Gast
Tooltime schrieb:
Sollte wohl ein "-f - ./"werden.
Zum Vergrößern anklicken....
Genau.
Das schreibt dann auf den Standardausgabekanal und wird von dort über Pipe weitergeleitet.
Im Howto stehts richtig, sowas am besten soweit wie möglich immer mit Kopieren und Einfügen übernehmen. Beim Abschreiben gibts bei solchen etwas komplizierteren Befehlsketten oftmals Abschreibfehler.

robi
 
T

Tooltime

Advanced Hacker
So weit ich weiss, erhöht dieses wienern nicht gerade die Lebensdauer von Streamer und Band. Du solltest zuerst einmal herausfinden welche Datenrate der Streamer kontinuierlich verarbeitet, Handbuch oder Hersteller, damit wir die minimal benötigte Datenrate kennen. Zum Testen bietet sich "| dd of=/dev/null" als Ausgabegerät für tar an, ein direktes schreiben mit "-f /dev/null" erkennt tar und liest erst garnicht die Daten von Festplatte, da sie eh verworfen werden. Der Befehl würde etwa so aussehen:
tar -cl -b 512 -f- ./ | dd of=/dev/null
oder die Transferleistung mit mbuffer
tar -cl -b 512 -f- ./ | /usr/local/bin/mbuffer -s 256k -m 1G -P 85 | dd of=/dev/null
Mit einem Sysmonitor (z.B. xosview) lässt sich der Datendurchsatz beobachten und dd liefert am Ende die durchschnittliche Transferrate. So kann man über den Daumen abschätzen ob tar überhaupt die nötige Datenrate liefert. Ich habe mir mal willkürlich ein Verzeichnis bei mir ausgewählt:
1964244992 Bytes (2,0 GB) kopiert, 50,2092 s, 39,1 MB/s
Deine 17MB/s sind nicht unbedingt Gigantisch sondern eher lahm (3 Jahre alte Platte, der Rest des Rechners ca. 5 Jahre alt). Sollte die Datentransferleistung von tar ausreichen, kann man mit "ionice" die I/O-prio auf realtime anheben, um eine kontinulierliche Datenversorgung des Streamers zu gewährleisten. Das funktioniert nur wenn das System cfq als I/O-Scheduler benutzt. Möglicher Weise steigt die I/O-Performance wenn man deadline als I/O-Scheduler benutzt, einfach beim Starten im Bootmanager den Parameter elevator=deadline eingeben. Es besteht auch die Möglichkeit im laufenden Betrieb bei einzelnen Geräten den I/O-Scheduler zu wechseln. (siehe dafür /usr/src/linux/Documentation/block/switching-sched.txt)

Liegt das Logfile von tar auch auf dem Raid-Controller, oder führt die Buffergröße (1GB) dazu das die Maschine swapt? Mehr fällt mir auf Anhieb nicht zu deinen Problem ein.
 
A

Anonymous

Gast
Ich habe mir das jetzt mal kurz nachgestellt, habe mich auch schon längere Zeit nicht mehr intensiver damit befasst.

Folgende Kurzinfo zum Rechner, Standardinstallation 10.3
Code: 
rob@server:~> uname -r
2.6.22.17-0.1-default
rob@server:/etc> cat SuSE-release 
openSUSE 10.3 (i586)
VERSION = 10.3
rob@server:~> rpm -qa | grep mbuffer
mbuffer-20070518-10
rob@server:~> free
             total       used       free     shared    buffers     cached
Mem:       2076320    2023744      52576          0       4128     634988
-/+ buffers/cache:    1384628     691692
Swap:      4200944        280    4200664
rob@server:~> grep "cpu MHz" < /proc/cpuinfo
cpu MHz         : 933.398
cpu MHz         : 933.398
rob@server:~> cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: HL-DT-ST Model: RW/DVD GCC-T10N  Rev: 1.02
  Type:   CD-ROM                           ANSI  SCSI revision: 05
Host: scsi2 Channel: 00 Id: 01 Lun: 00
  Vendor: SEAGATE  Model: ST336704LC       Rev: A600
  Type:   Direct-Access                    ANSI  SCSI revision: 03
Host: scsi2 Channel: 00 Id: 02 Lun: 00
  Vendor: SEAGATE  Model: ST336704LC       Rev: A600
  Type:   Direct-Access                    ANSI  SCSI revision: 03
Host: scsi2 Channel: 00 Id: 11 Lun: 00
  Vendor: SDR      Model: GEM318           Rev: 0   
  Type:   Processor                        ANSI  SCSI revision: 02
Host: scsi3 Channel: 00 Id: 01 Lun: 00
  Vendor: IBM      Model: ULTRIUM-TD1      Rev: 4561
  Type:   Sequential-Access                ANSI  SCSI revision: 03
rob@server:~>dmesg | more
......
DAC960#0: Configuring Mylex AcceleRAID 352 PCI RAID Controller
DAC960#0:   Firmware Version: 6.00-17, Channels: 2, Memory Size: 64MB
....
DAC960#0:     1:4  Vendor: MAXTOR    Model: ATLASU320_73_SCA  Revision: B434
DAC960#0:          Wide Synchronous at 160 MB/sec
DAC960#0:          Serial Number: 348
....
DAC960#0:   Logical Drives:
DAC960#0:     /dev/rd/c0d0: RAID-5, Online, 426393600 blocks
DAC960#0:                   Logical Device Initialized, BIOS Geometry: 255/63
DAC960#0:                   Stripe Size: 64KB, Segment Size: 8KB
DAC960#0:                   Read Cache Disabled, Write Cache Enabled
DAC960#0:     /dev/rd/c0d1: RAID-5, Online, 426393600 blocks
DAC960#0:                   Logical Device Initialized, BIOS Geometry: 255/63
DAC960#0:                   Stripe Size: 64KB, Segment Size: 8KB
DAC960#0:                   Read Cache Disabled, Write Cache Enabled
ich komme also bei Videodateien mit meinem LTO1 auf ein ähnliches Ergebniss wie du mit deinem LTO4 obwohl deines ca. 3 Mal schneller sein sollte.
Code: 
server:/raid/video/neu # tar -cl -b 512 -f- ./ 2>/tmp/tarpip.log | mbuffer -L -s 256k -m 1G -P 85 > /dev/nst0
mbuffer: warning: Could not stat output device (unsupported by system)!
This can result in incorrect written data when
using multiple volumes. Continue at your own risk!
in @  0.0 kB/s, out @  510 kB/s, 6708 MB total, buffer   0% full
summary: 6708 MB in  8 min 19.1 sec - average of 13.4 MB/s, 1x full

Tar war in der Lage (bis Buffer voll) ca. 40MB/s zu liefern. Laufwerk hat nur ca. 15MB/s abgenommen. Der Buffer war nach dem das Laufwerk angelaufen ist permanent auf 100%. Laufwerk permanet am Streamen. die 13.4 MB/s fallen etwas kleiner aus als die 15MB weil das Laufwerk am Anfang nichts gemacht hat, die Zeit aber mitzählt.
Videodateien sind erstens Groß und zweitens lassen sie sich nicht kompimieren, das LTO1 war also 100% ausgelastet.

Code: 
server:/raid1/data # tar -cl -b 512 -f- ./ 2>/tmp/tarpip.log | mbuffer -L -s 256k -m 1G -P 85 > /dev/nst0
mbuffer: warning: Could not stat output device (unsupported by system)!
This can result in incorrect written data when
using multiple volumes. Continue at your own risk!
in @  0.0 kB/s, out @ 3556 kB/s, 6740 MB total, buffer   0% full
summary: 6740 MB in  6 min 19.5 sec - average of 17.8 MB/s, 1x full
Hierbei handelte es sich um 4 große unkompimierte Backups von Homeverzeichnissen mit sehr vielen Bildern und einer Virtuellen Maschine. Die Datengeschwindigkeit am Ende von tar auch etwa 30MB/s im Durchschnitt, am Laufwerk hat es zwischen 13 und 63 MB/s geschwankt, Der Buffer war einige Male auf 97% unten. Das Laufwerk hat voll gestreamt war also voll ausgelastet.

Code: 
server:/raid/opt # tar -cl -b 512 -f- ./ ./ ./ ./ ./ ./ ./  2>/tmp/tarpip.log | mbuffer -L -s 256k -m 1G -P 85 > /dev/nst0
mbuffer: warning: Could not stat output device (unsupported by system)!
This can result in incorrect written data when
using multiple volumes. Continue at your own risk!
in @  0.0 kB/s, out @ 7619 kB/s, 6944 MB total, buffer   0% full
summary: 6944 MB in 10 min 6.7 sec - average of 11.4 MB/s, 6x full
Hierbei handelt es sich um das /opt/kde-Verzeichnis eines anderen Rechners das auf das selbe Raid kopiert wurde. Es wurde bei diesem Versuch 7 Mal in einem tar gesichert um in etwa auf die gleiche Datenmenge zu kommen. Die Datenrate von tar hat zwischen 1 MB/s und 25 MB/s geschwankt, typische Werte um die 5-10 MB/s. Das Laufwerk hat Datenraten zwischen 15MB/s und 65 MB/s abgenommen, typischer Wert so um die 25 bis 30. Der Buffer ist 5 Mal leer gelaufen und damit das Laufwerk angehalten worden bis der Buffer wieder voll war. Solange das Laufwerk gesichert hat, gab es nicht ein Start-Stop, in dieser Zeit war das Laufwerk also auch 100% ausgelastet. Die Gesamtgeschwindigkeit von 11 MB/s umfasst also auch die Zeit in der das Laufwerk nichts gemacht hat.

Bei dir sollte das LTO4 aber ungefähr die 3 Fache Geschwindigkeit an Daten abnehmen, das Ganze sich also bei dir extremer gestalten.

Wenn du wissen willst was dein Laufwerk im aller günstigsten Fall in der Lage währe für einen Datenstrom zu erhalten versuche mal folgendes.
Code: 
server:/raid/opt # dd if=/dev/zero bs=265K count=24000 | mbuffer -L -s 256k -m 1G -P 85 > /dev/nst0
mbuffer: warning: Could not stat output device (unsupported by system)!
This can result in incorrect written data when
using multiple volumes. Continue at your own risk!
in @ 70.4 MB/s, out @ 70.4 MB/s, 5168 MB total, buffer 100% full24000+0 Datensätze ein
24000+0 Datensätze aus
6512640000 Bytes (6,5 GB) kopiert, 80,0342 s, 81,4 MB/s
in @  0.0 kB/s, out @ 66.5 MB/s, 6182 MB total, buffer   3% fullmbuffer: warning: output does not support syncing: omitted.
in @  0.0 kB/s, out @ 58.1 MB/s, 6211 MB total, buffer   0% full
summary: 6211 MB in  1 min 32.6 sec - average of 67.1 MB/s, 1x full
allerdings wird das Laufwerk sich dabei zu tote Langweilen und kaum schreiben, weil es die Nullen fast unendlich kompimieren kann.

robi
 
OP
K

kaix.sh

Newbie
Tooltime und robi,
vielen Dank für die ausführlichen Informationen, das werde ich alles mal ausprobieren.

@Tooltime: Die logdatei liegt auf einer einzelnen JBOD-Platte am Controller, die Daten kommen aus einem RAID5 am selben Controller.
@robi: könnte ich statt /dev/zero nicht auch /dev/random nehmen? Oder ist das zu langsam?

Kai
 
A

Anonymous

Gast
kaix.sh schrieb:
@robi: könnte ich statt /dev/zero nicht auch /dev/random nehmen? Oder ist das zu langsam?
Zum Vergrößern anklicken....

/dev/random ist bei Linux von der Logig her sowas von grottenlahm, dass du dir wahrscheinlich schneller Zufallszahlen ausdenken kannst, dafür aber sowas von zufällig, soviel Zufall gibt es gar nicht. (nur für einzelne Werte geeignet, nicht für große Sequenzen)
Wenn schon dann /dev/urandom

dd if=/dev/urandom bs=256K count=24000
damit würdest du wahrscheinlich folgendes erreichen (ungetestet)
Nach einigen (vielen Minuten) ist der Buffer voll, das Laufwerk läuft los und hat nach einigen Sekunden den Buffer wieder leergesaugt. Dann geht das Spiel von vorne los.

Wenn du mit typischen Kompressionseigenschaften von Dateien experimentieren willst.
http://wiki.linux-club.de/opensuse/Dd#Erzeugen_einer_Datei_mit_typischen_Eigenschaften_und_genau_definierter_L.C3.A4nge
ZB. aus der /var/log/messages eine sehr große Datei (zB 1GB groß damit der Cache vom Filesystem uns nicht den ganzen Spaß wieder verdirbt) zusammenbasteln und diese dann mittels mehrfacher Angabe bei tar über mbuffer sichern. Auch Dateien mit Zufallszahlen oä. kannst du dir so zusammenbasteln und testen. Hier wirdst du dann enorme Unterschiede feststellen können zwischen dem Verhalten von mbuffer und Laufwerk je nach Komprimierungsgrad der Dateien. Das ist auch geeignet um auf einen speziellem Rechner und speziellem Laufwerk die richtigen Parameter für mbuffer speziell für typische Dateitypen (Datenbanken oä) herauszufinden die man sichern will. Oben aus den Beispielen kannst du ja gesehen, das ich mit meinem LTO1 Laufwerk beim Sichern von Videodateien also ganzen DVDs überhaupt kein mbuffer benötigen würde, für reine Bildverzeichnisse würde mir ein viel kleinerer Buffer vollkommen ausreichen, aber bei vielen kleinen und kleinsten Dateien und vielen Verzeichnissen auf ext3 Filesystem komme ich mit 1 GB recht gut aus.


robi
 
OP
K

kaix.sh

Newbie
Sooo,
nachdem ich mir ein paar Tage unglaublich zufällige Zufallszahlen zufällig ausgedacht habe, habe ich jetzt genug beisammen, um mal zu testen... :lol:
Code: 
dd if=/dev/zero bs=265K count=24000 | mbuffer -L -s 256k -m 1G -P 85 > /dev/nst0
ca. 181 MB/s (reproduzierbar).
Da das hdparm -t /dev/sdb nur 110 MB/s ergab, hats hier schonmal eine Differenz von 70 MB/s. Bei 1 GB Buffer ist selbiger also Pi x Daumen nach 14 Sekunden leer. Wahnsinnig praktisch.
Ich kam dann auf die Idee, dass es für die Performance durchaus von Vorteil sein könnte, wenn die im RAID steckenden Festplatten nicht bis zum Kragen vollgekippt sind.
Code: 
df -h
gibt denn auch 100% aus, weil von 1,82 TB nur noch 480 MB frei sind.
Also flugs noch 2x 1 TB reingesteckt und nicht ganz so flugs das RAID migriert. Kann man zwar währenddessen weiterbenutzen, aber es rödelt halt gute 36 h (oder so).
Soo, danach ergibt
Code: 
hdparm -t /dev/sdb
dann auch etwas schönere 160 MB/s. Damit wäre der Buffer erst nach 51 Sekunden leer. Um diese Zeit zu erhöhen, bekommt der Rechner übermorgen nochmal 6 GB Speicher, damit würde der Streamer über de Daumen gepeilt ungefähr 5-6 Minuten durchlaufen.
tar scheint auch fix genug zu sein, es sei denn, ich habe mich hier völlig "verinterpretiert":
Code: 
backupserver:/daten # tar -cl -b 512 -f- ./ | /usr/local/bin/mbuffer -s 256k -m 1G -P85|dd of=/dev/null
in @  225 MB/s, out @  299 MB/s, 26.0 GB total, buffer  11% full54881234+0 records in
54881233+0 records out
28099191296 bytes (28 GB) copied, 135.013 s, 208 MB/s
mbuffer: error: outputThread: error writing at offset 68ad89000: Broken pipe
in @  204 MB/s, out @  270 MB/s, 26.2 GB total, buffer   8% full
summary: 26.2 GByte in  2 min 15.0 sec - average of  198 MB/s, 10x empty
Was sagt mir den die "Broken pipe" bei mbuffer? Nanu?

Also, neue Meldung gibt es, sobald der Speicher eingebaut ist, dann werde ich einen neuen Versuch starten, bevor *bibber* ich die Partition mit grow_xfs vergrößere...

VG

Kai
 
T

Tooltime

Advanced Hacker
Ok, ich habe ein bischen gepennt!
Code: 
| dd bs=256k of=/dev/null
dürfte besser seien. Die Meldungen von dd sind mit denen von mbuffer verschmolzen.
dd sagt:
Code: 
54881234+0 records in
54881233+0 records out
28099191296 bytes (28 GB) copied, 135.013 s, 208 MB/s
Ich denke das der letzte 256k-Block nur wenige Datenbytes enthielt und mit Nullen aufgefüllt wurde, um die geforderten 256kB zu erreichen. Wenn ich mich recht erinnere, stellen Nullen eine Endekennung für Streams und Dateien dar. Da dd eine kleinere Blockgröße benutzt hat, beendete er vorzeitig den Datentransfer. Das erklärt warum ein Datenblock weniger geschrieben als gelesen wurde. Wahrscheinlich führte das wiederum dazu, das der Buffer der Pipe nicht vollständig ausgelesen wurde und somit für mBuffer der Datentransfer nicht korrekt beendet wurde. Das Resultat die broken pipe. Aber dd sollte sowie so nur zur Kontrolle der Schreibgeschwindigkeit dienen.

Also viel Glück!
 
A

Anonymous

Gast
kaix.sh schrieb:
Code: 
dd if=/dev/zero bs=265K count=24000 | mbuffer -L -s 256k -m 1G -P 85 > /dev/nst0
ca. 181 MB/s (reproduzierbar).
Da das hdparm -t /dev/sdb nur 110 MB/s ergab, hats hier schonmal eine Differenz von 70 MB/s. Bei 1 GB Buffer ist selbiger also Pi x Daumen nach 14 Sekunden leer. Wahnsinnig praktisch.
Zum Vergrößern anklicken....
Na ich hoffe mal, dass du deine schönen Raidbüchsen nicht nur zum Nullen stapeln brauchst, Wenn du normale Daten an das Laufwerk sendest dann wird es längst nicht so hungrig sein. Den Buffer solltest du ungefähr so bemessen und einstellen, dass das Laufwerk mit den bei dir vorherrschenden Dateien 2 bis 3 Minuten am Stück arbeiten kann solange hinten die Daten normal schnell reinkommen.. Das sollte schon ausreichen, also brauchst du nicht unbedingt noch extra Speicher-Reiserkarten um deinen Hauptspeicher unnötig aufzublasen, außer du kaufst den Speicher natürlich bei meiner Firma ;-) ich kenne da so einige, die würden dir noch ein paar 4 oder 8GB-Streifen verkaufen ;-) . Wenn das Laufwerk schnell genug ist, kannst du auch die obere Wasserstandsmarke am mbuffer weiter hochziehen, im Moment ist sie bei 85% könnte also noch 10% hoch, 5% solltest du jedoch für die Anlaufverzögerung des Laufwerks reservieren.

robi
 
OP
K

kaix.sh

Newbie
So, kurze Meldung mal eben (auch wenns keinen Interessiert ;) )
Mittlerweile habe ich gelernt, wie man Treiber kompiliert / lädt / schaut, ob sie da sind / obs beim laden Probleme gibt.
Außerdem sind SAS-Kabel trotz des massiven Metallgehäuses scheinbar doch nicht so kontaktfreudig.
Das ursprüngliche Problem ist noch nicht gelöst, aber der [del]bulgarisch[/del] deutschsprachige Support von hp kümmert sich ein wenig drum und nimmt mal das logfile des Laufwerkstestes unter die Lupe...
Bis demnächst!

Kai
 
OP
K

kaix.sh

Newbie
Okay, das war auch mehr humoristisch gemeint und bezog sich im Wesentlichen auch auf den Zwischenstand :D . Wenn es - hoffentlich bald - eine Lösung gibt, wird die hier natürlich auch gepostet!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben