Problem: sarge software raid Installtion mit promise 133 TX2

[ThorstenS]

Hallo Leute,
ich habe gestern meinen Server mit der neuen Hardware installiert:
- 2*200 GB (hda, hdc) jeweils als Master am primary und secondary Kanal
- 1*160 GB (hde) als Master am promise Ultra 133 TX2
Ich habe nur neue UDMA133 Kabel verbaut. Das CDROM meldete sich
im UDMA2 Modus, tausche ich gleich nochmal gegen einen DVD Brenner (hdf)

Die Partitionierung:

Code: Alles auswählen

/boot: md0, Raid1 mit hda1,hdb1           50MB
swap : md2, Raid1 mit hda2,hdc2,hde1     256MB
/    : md1, Raid1 mit hda3,hdc3           40GB
/home: md3, Raid5 mit hda4,hdc4,hde2     160GB (ergibt 320GB netto)

(das BIOS erkennt nur 80GB, daher die /boot Partition unter der 1024 Zylinder Grenze. Andernfaslls meldet grup error 18)

Nach einer Installation mit dem aktuellsten sarge installer (der dieses
Raid perfekt angelegt hat) habe ich beim synchronisieren des Raids
eine schreibende Datenrate von ~30MB/sec in /proc/mdstat gelesen.
Das ist einbischen mau würde ich sagen.

Also flux hdparm installiert und folgendes aufgerufen:
hdparm -d1 -c1 -m16 /dev/hd{a,c,e}
Die neuen Modi wurden gesetzt, aber nach wenigen Sekunden hagelte
es 'drive seek complete error' & Co, der Rechner ist eingefroren.
Nach einem Neustart waren sämtliche Partitionen verschwunden
- alles futsch =:-o
Das fdisk von Knoppix hat mir quasi jungfräuliche Festplatten
angezeigt.

Mit einem neuen Versuch sieht die Installation genauso aus, ich habe dann nur hda und hdc mit meinen hdparm Einstellungen beglückt und das Raid lief soweit.
Nachdem die große Partition mitten im resync steckt, hagelt es ext3-filesystem errors md(9,1) - das sagt mir nun überhaupt nichts.

Also Knoppix 3.7 angeworfen und die Platten nochmals partitioniert und ein Raid händisch angelegt.
Vor dem Aktivieren des Raids habe ich die Platten mit 'hdparm -t' getestet:
61MB/sec an den mb-controllern und 53MB/sec lesend an dem promise controller.
Im Raid fällt dann allerdings hdc auf 16MB/sec zurück.

Ich habe danach 'smartctl -t long' auf alle Platten losgelassen und nach 82 Minuten wieder ausgelesen: Die Platten haben keinen smart Fehler gemeldet (sind ja auch neu).

Tja und nun bin ich soweit am Ende mit meinem Latein, hat jemand eine Idee, wie ich mein Softwareraid doch noch mit dieser Hardware nutzen kann?
(Vielen Dank, falls sich wirklich jemand die Mühe macht und das hier alles gelesen hat!)

[HardHat]

Ich finde 30 MB/s für den resync ist gut. Es kann durchaus sein, dass die Durchsatzrate eines Software Raid 5 nicht der Rate entspricht, die du von den beteiligten Platten im einzelnen erhälst. Du musst nämlich bedenken, dass das, was da auf die Platten mit 50 oder 60 MB/s geschrieben werden soll, die Redundanzinformation ist. Und die muss der Prozessor erst berechnen... und das dauert. Ich denke deinen Platten könnten also durchaus schneller, aber sie bekommen die Daten zum Schreiben nicht schnell genug und warten deshalb quasi einen Teil der Zeit untätig. Wie gesagt: ich finde 30 MB/s für ein Software RAID 5 einen wirklich guten Durchsatz. Zu den verschiedenen Abstürzen und Datenverlusten, die du beschrieben hast, kann ich dir aber leider auch nichts sagen :-/

[ThorstenS]

Danke für deinen Post, aber wenn die eine Platte beim resync nicht nur lesend 16MB machen würde, hätte ich mindestens 45-50MB.

An einem aktuellen SCSI System habe ich Anfang der Woche 57MB/sec gesehen und so sehr viel langsamer sind die PATA Platten auch wieder nicht.
(Daher habe ich ja extra jeder Platte einen eigenen Kontroller geschenkt...) Und die Berechnung der parity Daten ist nicht so aufwändig, der load lag beim resync bei 0.2

Aber ob nun 30MB oder nicht, mit den Abstürzen kann ich nicht leben, denn die versauen mir innerhalb kürzester Zeit die gesamte Installation. Da will ich keine Daten drauf sichern.

[HardHat]

Schau doch mal in /proc/interrupts nach, ob der ERROR Wert deutlich größer 0 ist (>>0) und wenn ja, ob er beim Zugriff auf die Platten, (im besonderen: beim Zugriff auf die Platte am Promise Controller hängt) ansteigt. Wenn das so ist, dann liegt das Problem am Promise Controller.

Ich hatte auch mal ein System mit zwei Promise 100 TX2 Controllern und hatte ständig Probleme damit. Der hohe ERROR Zähler in /proc/interrupts war immer eindeutiger Idikator dafür, dass das etwas nicht so funktioniert, wie es soll. Letztlich hat es nur geholfen, die Controller gegen andere von einer Konkurrenzfirma auszutauschen. Ich habe mir nach dem Ärger geschworen nie wieder Promise Produkte zu kaufen.

Als Schmakerl: Hab' gerade mal gesucht und sogar noch den von mir seinerzeit auf bugzilla.kernel.org geposteten Bug-Report gefunden: http://bugzilla.kernel.org/show_bug.cgi?id=1556

[ThorstenS]

Hey klasse, das ist eine gfute Idee.
Ich habe entferne dann sicherheitshalber auch alle weiteren PCI Karten, um den Fehler einzugrenzen

Ich habe gerade zwei 80er Lüfter vor die Platten gehängt, die Temperatur lag bei der obersten Platte (hdc) mit 46°C auch viel zu hoch.

[ThorstenS]

Also /proc/interrupts war sauber, da sind keine Fehler gewesen.
Ich habe trotzdem nochmal die überflüssige Soundkarte entfernt und im BIOS den parallelen und diebeiden seriellen Anschlüsse deaktiviert.
Ausserdem habe ich die kernel Option acpi=off mitgegeben.

Dann hat es erstmal soweit funktioniert!

Dumemrweise kam heute Abend ein Update für den kernel und mdadm rein. Letzteres Packet wollte, dass ich unter Umständen mdam --zero-superblock /dev/XYZ ausführen muss, falls ich noch alte raidpartitionen habe (oder so ähnlich).
Das habe ich nicht gemacht und nach einem Neustart und wiederholten hdparm -d1 Aufruf (so wie er vorher dann funktionierte), habe ich wieder alles verloren.
Im mbr ist keine Info mehr zur Partitionierung zu finden

Ich habe erstmal die Schnauze voll, jetzt habe ich schon 2 Abende umsonst vorm Rechner verbracht.

Ich warte erstmal ab, ob sich noch mehr Leute über das neue mdadm Packet beschweren und die negativen Folgen

[ThorstenS]

Habe den Thread eben mal wiedegefunden und möchte zur Lösung sagen:
Das mainboard war hin! Ich habe den Rechner ausgetauscht und nun rennt der Server seit geraumer Zeit stabil wie er soll.