Donnerstag, 3. März 2011, 11:10
mdadm-Metadaten
Kleiner Tipp, wer aktuelle mdadm-Versionen verwendet und es hinterher nicht so funktioniert, wie gewünscht und gewohnt: 
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).
mdadm --metadata=0.90wirkt 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
Manchmal sind solche Dinge ja durchaus kompliziert und umständlich gelöst.
MOW
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
Beim RAID kann man wenigstens noch über Kernelparameter das Array ohne Autoerkennung bauen lassen.
MOW
Energiequant
Für Boot-Partitionen ist zwar auch ein bestimmtes Format erforderlich, bei anderen Partitionen müsste es aber egal sein?
MOW
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 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
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