Skip to content

mdadm-Metadaten

Kleiner Tipp, wer aktuelle mdadm-Versionen verwendet und es hinterher nicht so funktioniert, wie gewünscht und gewohnt: wirkt Wunder :-|

Und nein: Ein nachträgliches Ändern ist nicht ohne Weiteres möglich. Da heißt es: Array degraden, parallel degradiertes zweites Array aufbauen, zweimal mounten, Daten kopieren (besser: synchronisieren), erstes Array zerstören (inkl. Superblock), zweites Array stoppen, neues Array aus der richtigen Komponente und der nun leeren Partition zusammenbauen (was dann auch die Namensänderung ergibt).

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Andreas

Wie gut dass das so simpel ist.
Manchmal sind solche Dinge ja durchaus kompliziert und umständlich gelöst.

MOW

Oh, seit wann ist 0.90 nicht mehr der Default?

Und im Kernel sind immer noch nicht md.c:autorun_devices() und autostart_arrays() angepaßt ... hat das politische Gründe? Allzu aufwendig scheinen die nötigen Änderungen ja nicht zu sein ...

Tetja Rediske

Soweit ich weiß wollen die Kernel Maintainer alles was ins Userland ausgelagert werden kann auch auslagern, sprich wer RAID, btrfs (Wenn mehr als ein Physical-Volume enthalten ist) oder ähnliches als / haben will soll eine Init-Ram-Disk verwenden und dem Rest ist es egal.

Beim RAID kann man wenigstens noch über Kernelparameter das Array ohne Autoerkennung bauen lassen.

MOW

Okay, das #ifndef MODULE sieht auch sehr danach aus, daß die maintainer meinen, wer schon ne initrd baut, kann auch mdadm + .conf draufpacken.

Energiequant

Was funktioniert denn nicht? Laut https://raid.wiki.kernel.org/index.php/RAID_superblock_formats läuft zwar LILO nur mit 0.90 und die Unterschiede sind für den "Otto Normal"-Betrieb nicht von Bedeutung (< 2 TB), aber Probleme im Betrieb sollte es eigentlich keine geben? (davon abgesehen, daß es ggf. aktuellere Rescue-Images, Live-CDs o.ä. braucht)

Für Boot-Partitionen ist zwar auch ein bestimmtes Format erforderlich, bei anderen Partitionen müsste es aber egal sein?

MOW

Der kernel baut RAIDs nur automatisch zusammen, wenn sie eieinen 0.90-Superblock haben. Alle anderen muß man über mdadm zusammenbauen.
Damit man von einem RAID1 mit 1.x-Superblock booten kann, muß man also mdadm und ein entsprechendes Skript in der initrd haben oder die Teile des RAIDs explizit angeben, so schön automatisch wie mit 0.90 geht das nicht.
Wäre eigentlich kein großes Problem, das dem Kernel beizubringen, aber wie oben schon gesagt ... politische Entscheidung.

Für normale Fälle sollte es reichen, einen mdadm-Aufruf in die Initskripte einzubauen und ggf. die /etc/mdadm.conf zu pflegen, aber das steht schonmal in den meisten RAID-Tutorials nicht drin und dürfte daher bei vielen Leuten für Überraschungen sorgen.

Übrigens, man sollte beim --assemble besser das --scan bzw. das md-Device nicht vergessen, sonst brettert mdadm das unglücklicherweise an erster Stelle der folgenden Liste stehende Device mit dem RAID-Device über, und man muß dann erstmal mit mknod bei um den Zugriff wieder zu ermöglichen ...

Manuel Schmitt (manitu)

Ich spreche mich im übrigen gegen das nicht-automatische Zusammenbauen aus - aus der Sicht eines Rechenzentrums. Wegen mir via Kernel-Config-Option, die aber das bisherige Verhalten als Standard beinhalten sollte.

Ich erahne jetzt schon, wieviele Admins nicht mehr an ihren Server kommen werden, weil ihnen / etc. pp "weggeflogen" ist. Für mich und uns ist es wichtig, dass ein Server quasi unter allen Umständen wieder bootet, mit dem nötigen /-Dateisystem und mindestens ssh. Deswegen sind wir auch Freude eines großen, monolitischen Kernels, der für die wichtigste Hardware Treiber mitbringt.

Als Alternative könnte ich mich dafür erweichen, die Information, ob das Array per default vom Kernel zusammengebaut werden soll oder nicht, in die Metadaten als boolean Parameter wandert.

MOW

Zustimmung - es hat mich bei der Slackware auch gewurmt, daß im Kernel zwar die (S)ATA-Treiber, aber keine fürs Filesystem sind; ich habe auch gerne alles fest eingebaut, was die Kiste zum Booten braucht.
Aber die politische Linie ist wohl, daß alles, was sich nicht im Kernel festgebissen hat, in die initrd soll.

Da hängt aber, wie oben schon von Energiequant erwähnt, noch mehr dran - um vom RAID1 zu booten (andere Level gehen ja eh nicht) muß ja nicht nur der Kernel, sondern auch der Bootloader 1.x unterstützen. Ein (wohl relativ simpler) Kernel-Patch würde das eine lösen, aber nicht das andere. Von daher sehe ich den Schwarzen Peter eigentlich nicht so sehr bei den Kernel-Leuten, sondern eher bei dem, der den Default bei mdadm geändert hat.

Eine entsprechende Warnung zum Thema auto-assemble habe ich zwar gefunden, aber nicht in der mdadm-manpage, wo sie mbMn hingehört.
Hat sich denn wirklich der eingebaute mdadm-Default geändert, oder hat der Packager eine mdadm.conf untergejubelt, wo der Default bei CREATE auf 1.x gestellt ist?

Energiequant

Hm, das ist wirklich doof... Ich bin eigentlich davon ausgegangen, daß das kein Problem sein dürfte, die RAID-Partitionen sind ja eh als Typ FD gekennzeichnet. Hab bisher auch erst eine Backuppartition versehentlich auf 1.2 setzen lassen, aber gut zu wissen, daß man wegen dem Auto-Detect aufpassen muss, welche Partitionen aufs neue Format kommen. Auf initrd hab ich aus Prinzip keine Lust, kann aber andererseits auch den Wunsch, alles unnötige langfristig aus dem Kernel an sich zu entfernen nachvollziehen.

Kommentar schreiben

Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

BBCode-Formatierung erlaubt
Formular-Optionen