[GELÖST] MDraid + Ext4 → RAID10 arbeitet extrem instabil

[generalmajor]

Ja, ich habe den Schirm mit dem Handy abgelichtet und dann abgeschrieben. Sehr primitiv.

Das Ausnullen der Superblöcke ist übrigens unerlässlich (sonst lässt sich die Partition gar nicht erst ins RAID einpflanzen), doch helfen tut es nur eingeschränkt. Jetzt habe ich /* auch mit dem Trick, vorerst nur 2 Partis einzubinden */ immerhin 3 von 4 Partis einbauen können. Die vierte nimmt mdadm --add zwar, sagt «device added», doch nach ½ Stunde Recovery heißt es wieder, sie sei ein «faulty spare».

 

[generalmajor]

Nach einigen Experimenten mit Ubuntu und openSuSE 12.1 machte ich nochmal Tabula rasa, nullte alle Superblöcke aus, stampfte sämtliche Mitglieds-Partitionen meines RAIDs ein und fabrizierte das RAID 10 komplett von Hand (auf der Rescue-Shell; der grafische Installer fährt generell alles gegen die Wand :-(). Reboot, und schon stehen vier kaputte RAIDs (mit je einer Parti und Level 0) in /proc/mdstat. Alle vier gestoppt, mein von Hand definiertes md1 assembliert, 90 Minuten (!) gewartet (so lange brauchte er für den Restore)…und siehe da, es funktioniert! Zwar irritiert mich, dass der Installer gleich /dev/md127p1 (!) draus macht (ich habe /dev/md1 gesagt!!!), soch immerhin konnte ich ein openSuSE 12.1 drauf packen.

Was noch nicht geklappt hat, war die Installation des Bootloaders. Standardmäßig kommt er ja in den MBR (bei mir also /dev/sda), und /boot liegt auf einem separaten RAID 1 (/dev/md126p1), das aber vorher schon funktioniert hat. Da legt sich GRUB quer, weil er das Ziel hd(0,0) angeblich nicht finden kann…

Was ich gelernt habe: Auf keinen Fall sich auf die grafische Festplatten-Einrichtung verlassen, wenn man ein MD-RAID anlegen will! Offenbar wartet der Installer nicht darauf, dass mdadm --add mit seiner (mitunter recht langwierigen) Arbeit fertig ist, und dann kommen krude Fehlermeldungen wie «device or resource is busy», oder man steht sogar mit einem kaputten RAID da und verliert Daten.

 

[Anonymous]

Zwar irritiert mich, dass der Installer gleich /dev/md127p1 (!) draus macht (ich habe /dev/md1 gesagt!!!), soch immerhin konnte ich ein openSuSE 12.1 drauf packen.

das er das Raid umbenennt wenn es vorher in einem anderem System konfiguriert wurde ist, erklärbar, normal und auch richtig. Ich hatte das ja bei meinem "Bauplan" (oben) auch schon angedeutet. Wenn das stören sollte es lässt sich auch später wieder umbenennen. Die Erklärung warum das Raid umbenannt wird, könnte ich geben, sollte es wirklich benötigt werden.

Was noch nicht geklappt hat, war die Installation des Bootloaders. Standardmäßig kommt er ja in den MBR (bei mir also /dev/sda), und /boot liegt auf einem separaten RAID 1 (/dev/md126p1), das aber vorher schon funktioniert hat. Da legt sich GRUB quer, weil er das Ziel hd(0,0) angeblich nicht finden kann…

Leider schreibst du nicht wie du dieses versucht hast. Hier die empfohlene Vorgehensweise bei Grub. Es gibt noch andere Methoden zB alle Platten mit identischem Bootloder und dann alle bootbar machen indem man in /boot/grub/device.map alle Platte als hd0 deklariert, diese Vorgehensweise ist aber nicht sauber. Andere Varianten sind auch noch möglich, man muss dazu aber sich etwas näher mit Grub befassen und zB sehr genau wissen was bei der Grubkonfiguration warum wohin in Stage1 und Stage1.5 geschrieben wird.
Wichtig bei Grub ab 10.3 , die /boot/grub von laufenden System anpassen und später nie von Yast aus den Bootmanager von Yast anfassen. Yast würde das gnadenlos umkonfigurieren sobald man dort nicht kategorisch sagt er soll alle eventuellen Änderungen verwerfen. Wenn man sich daran hält bleibt die Konfiguration auch nach Kernelupdates und ähnlichen immer vollkommen intakt.

Was ich gelernt habe: Auf keinen Fall sich auf die grafische Festplatten-Einrichtung verlassen, wenn man ein MD-RAID anlegen will!

Auf keine grafische Oberfläche verlassen von der nicht 100% bekannt ist was im Hintergrund genau abgeht, sobald man eine etwas ausgefallenere Konfiguration hat, und das nicht nur bei der Installation sondern auch bei der späteren Konfiguration im laufenden Betrieb.


robi

 

[generalmajor]

Leider schreibst du nicht wie du dieses versucht hast.

Siehe: http://www.linux-club.de/viewtopic.php?f=4&t=117140&p=739694#p739694

Ich habe den Fall in einen separaten Thread ausgelagert, denn es ist eigentlich nur ein Folgeproblem von meinem MD-Raid-Gfrett.

 

[generalmajor]

Gerade habe ich mein Raid 10 einem Burn-in-Test unterzogen: Kopieren eines ganzen Wustes an Altdaten.

Die ersten beiden Häppchen (114 MB und 281 MB) liefen problemlos über die Bühne, doch mit meinem Fotoalbum (142 GB) begann es nach einigen Minuten Fehlermeldungen zu hageln, und zwar genau die gleichen, wie bei meinem ersten Test weiter oben. Erste war es eine Seite voll mit Meldungen wie die ersten beiden weiter unten (während die Festplatten offenbar stark unter Last standen), doch nochmal einige Minuten später kamen die Meldungen weiter unten. Das alles mündete in eine Kernel Panic. :-(

ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: status { DRDY }

end_request: dev sda, sector 571919630
ata3.00: revalidation failed (errno=5)
md/raid10:md126: Disk error on sdc2, disabling device.
md/raid10:md126: Operation continuing on 2 devices.
ata1.00: failed command: FLUSH CACHE EXT
ata1.00: status { DRDY }
ata1.00: revalidation failed (errno=5)
ata2.00: revalidation failed (errno=5)

Buffer I/O error on device md126, logical block 0
EXT4-fs error (device md126): ext_journal_start.sb:327: Detected aborted journal.
EXT4-fs (md126): ext4_da_writepages: jbd2_start: 5385 pages, ino 35651738, err -30
Kernel panic — not syncing: Attempted to kill init!

Irgendwie habe ich den Verdacht, meine Konstruktion habe ein Lastproblem. Oder wie sehr Ihr es…?

 

[josef-wien]

ata1.00: failed command: WRITE FPDMA QUEUED

Mangels praktischer Erfahrungen theoretisiere ich nur. Wenn nur ata1.00 betroffen ist, könnten diese Platte oder die Qualität des Datenkabels das Problem verursachen. Wenn auch ata2.00, ata3.00 und ata4.00 betroffen sind, könnten es immer noch alle Datenkabel sein, es könnte auch der Controller ein Problem haben, alle vier Platten gleichzeitig zu bedienen, und es könnte auch ein anderer Defekt des Controllers sein. Weitere "könnte" dürfen andere Mitglieder beisteuern.

 

[generalmajor]

Wie gesagt: Ich habe mit den Datenkabeln schon ein wenig rumprobiert, aber vielleicht waren sie alle von schlechter Qualität…who knows…

Heute habe ich den Altdaten-Import nochmals probiert. Meldungen wie in den ersten beiden Zeilen tauchten schon nach 80 Sekunden und dann alle paar Minuten auf, doch diesmal wurde die Aktion erfolgreich abgeschlossen: 142 GB in 84 Minuten wechselten die Platte. Im laufenden Betrieb werden solche Massendaten-Kopieraktionen nicht mehr stattfinden, also bin ich schon mal recht beruhigt.

Das «failed command» klingt natürlich etwas bedrohlich, doch die Daten waren zum Schluss allesamt in bester Ordnung, ist das Ganze wohl eher als Warnmeldung zu verstehen.

 

[Anonymous]

Ich glaube mal, damit wirst du nicht viel Freude haben. Da ist irgendwo ein nicht genau identifizierbares Problem das jederzeit wieder zuschlagen könnte, bis zum Absturz, das Problem kann dir Daten verfälschen oder durch Fehler Dateien nicht komplett schreiben, also Daten für immer verlieren.
Du wolltest Raid10 wegen Performance, und genau als du dem Laufwerk solche abgefordert hast, ist es wiederholt passiert :???:

Ich würde noch ein bisschen ausprobieren und spielen bevor ich damit arbeiten würde.
versuchen 2 Platten vom Raid 10 auf's Systemboard; nach Linux Treiber für Kontroller, Problemen damit und Bugs googlen (für frühere Linuxversionen gabs eventuell einen vorm Hersteller, jetzt sieht's wohl so aus aus, wie im Standard Sata-Treiber integriert)

robi

 

[generalmajor]

versuchen 2 Platten vom Raid 10 auf's Systemboard

Das klappt bei mir nicht, denn ich habe onboard nur noch einen einzigen Anschluss frei.

Immerhin wird auf https://ata.wiki.kernel.org/index.php/Libata_error_messages der Fehler näher beschrieben:

TIMEOUT
Controller failed to respond to an active ATA command. This could be any number of causes. Most often this is due to an unrelated interrupt subsystem bug (try booting with 'pci=nomsi' or 'acpi=off' or 'noapic'), which failed to deliver an interrupt when we were expecting one from the hardware.

Letztes Mal ließ ich top und free mitlaufen, um die CPU- und RAM-Auslastung zu prüfen. Ergebnis: CPU bei max. 6%, und vom RAM sind 120 MB belegt, der Rest für Puffer & Cache frei. H.i.K.: Das System als solches ist offenbar doch nicht zu lahmarschig für mein Raid.

nach Linux Treiber für Kontroller, Problemen damit und Bugs googlen (für frühere Linuxversionen gabs eventuell einen vorm Hersteller, jetzt sieht's wohl so aus aus, wie im Standard Sata-Treiber integriert)

Vom Chiphersteller Marvell gibt's nix, habe ich schon geschaut. Was meine Fehlermeldungen angeht, habe ich allerdings rausgefunden, dass einige SATA-3-Anwender die gleichen Probleme haben (auch ohne Raid, aber gehäuft bei SSDs) und ein Tausch von Festplatten und Controller keinen Erfolg brachte. Bei manchen (aber nicht bei allen!) hat ein simpler Kabeltausch Abhilfe verschafft, bei einem anderen User half nur die Drosselung des SATA-Anschlusses auf SATA-2-Tempo.

Nachtrag: Ich lese gerade von einem User, der einen Nvidia MCP55 als Chipsatz im Einsatz hat und mit den gleichen Problemen zu kämpfen hat. Also wird es eher kein Treiberproblem sein…

 

[josef-wien]

denn ich habe onboard nur noch einen einzigen Anschluss frei.

Hast Du jetzt auf den vier neuen Platten ein bootfähiges System, sodaß die bisherigen zwei Platten für einen Systemstart nicht notwendig sind? Wenn die Antwort "ja" lautet, muß ich fragen, warum Du Betriebssystem und Daten auf einer gemeinsamen Partition hast. Wenn die Antwort "nein" lautet, muß ich fragen, wozu Du eine Partition für /boot eingerichtet hast.

 

[generalmajor]

Hast Du jetzt auf den vier neuen Platten ein bootfähiges System, sodaß die bisherigen zwei Platten für einen Systemstart nicht notwendig sind?

So ist es. Die alten Platten habe ich soeben ins Archiv befördert, denn auf den neuen Platten funzt alles so, wie es sich gehört! ^^

Wenn die Antwort "ja" lautet, muß ich fragen, warum Du Betriebssystem und Daten auf einer gemeinsamen Partition hast.

Natürlich hätte ich auf den Installer hören und das Raid 10 partitionieren können (oder gleich zwei Raids für System & Nutzdaten erstellen können). Das hätte mein System aber weiter verkompliziert, und ehrlich gesagt: Ich bin so was von heilfroh, dass das ganze Werkl jetzt endlich rennt! *Stirn abwisch*

 

[josef-wien]

Ich stimme robi zu, daß Du Dich nicht auf Dein eher instabiles System verlassen solltest. Ich würde die vier neuen Platten an die mainboard-Anschlüsse anschließen und die Daten des RAID10 an einen anderen Ort auf dem RAID10 kopieren. Wenn nun keine Fehlermeldungen auftauchen, muß wohl der PCIe-Controller zum Problem gehören, dann würde ich die beiden alten Platten an den PCIe-Controller anschließen, das RAID1 nur lesend einhängen und schauen, was jetzt beim Kopieren auf das RAID10 passiert (wenn es schneller geht als bei Deiner gestern um 20:47 Uhr beschriebenen Aktion, würde mich das nicht wundern). Aber es ist Dein System, und wenn Deine Daten wichtig sind, wirst Du sie ohnehin regelmäßig sichern.

Wenn Du einmal Dein System neu installieren willst (oder mußt), wird Dich die gemeinsame System- und Datenpartition ziemlich reuen. Noch ist es Zeit, das mit wenig Aufwand zu ändern.

 

[generalmajor]

Ich hatte schon fix vor, die Raid-Platten onboard anzuschließen und nur noch das DVD-Laufwerk am Controller hängen zu lassen (die Kopieraktion hat geklappt; ich habe die Daten von Hand geprüft), wollte ein letztes Backup ziehen…und was macht der Controller? Er wird gar nicht mehr erkannt (und zwar noch in der BIOS-Phase)! Erst nach 2× Hard Reset lief alles so, als wäre nix passiert. Im laufenden Betrieb (noch bevor ich größere OPs an den Daten auf dem Raid durchführen konnte) gab es einen Absturz mit folgender Meldung (gekürzt, denn der USB-Stick-Trick funzte hier nicht):

Entering emergency mode. Press ^D to switch to default mode.
Input/output error

Ein Hard-Reset, und alles funzte wieder. Sogar das Raid musste nicht wiederhergestellt werden, sondern lief klaglos weiter.

H.i.K.: Als «Schuldiger» kommt eigentlich nur noch die Controllerkarte in Betracht. Ich habe schon ein neues Modell ausgesucht, doch von wem stammt dessen Chipsatz? Natürlich von MARVELL!!

P/S: Den Controller hat's jetzt vollends erwischt: Er wird überhaupt nicht mehr erkannt und lässt in Einzelfällen das System gar nicht mehr hochfahren (Kurzschluss?)! So habe ich erzwungenermaßen die Platten an die vier Onboard-SATA-Anschlüsse angesteckt und den Controller ausgebaut. Freilich ist jetzt das DVD-Laufwerk abgesteckt, aber das kann ich kurzfristig ja noch verschmerzen.