Donnerstag, 3. März 2011
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).
Trackbacks
Trackback-URL für diesen Eintrag
Keine Trackbacks
Kommentare
Ansicht der Kommentare:
(Linear | Verschachtelt)
Wie gut dass das so simpel ist.
Manchmal sind solche Dinge ja durchaus kompliziert und umständlich gelöst.
Manchmal sind solche Dinge ja durchaus kompliziert und umständlich gelöst.
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 ...
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 ...
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.
Beim RAID kann man wenigstens noch über Kernelparameter das Array ohne Autoerkennung bauen lassen.
Okay, das #ifndef MODULE sieht auch sehr danach aus, daß die maintainer meinen, wer schon ne initrd baut, kann auch mdadm + .conf draufpacken.
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?
Für Boot-Partitionen ist zwar auch ein bestimmtes Format erforderlich, bei anderen Partitionen müsste es aber egal sein?
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 ...
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 ...
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.
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.
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?
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?
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.
IPv4 vs. IPv6
Du bist hier via
Suche
Ökostrom
Kalender
Kommentare
zu Hochtourig
Sa, 26.05.2012 02:28
At present, many excellent pla
yers have already in big games
in adizero [url=http://www.newairyeezy2.com][b]kanye [...]
Sa, 26.05.2012 00:19
Naja die meisten Kunden sind h
alt keine Experten, wenn in me
inem Fenster eine Werbetafel e
röffnet werden würde, da [...]
Fr, 25.05.2012 23:17
http://blog.fefe.de/?ts=b14989
2a
Besser?
Zitat: "Micro
soft erwirkt Einfuhrstopp für
Android-Geräte von Motor [...]
Fr, 25.05.2012 19:46
Arbeit anderer 1:1 kopieren !=
dem was die Patenttrolle mome
ntan veranstalten.
Fr, 25.05.2012 18:54
Naja ne AGB ist ja auch schnel
l geschrieben, aber kaum wird
sie kopiert ist das geschrei g
roß
Do, 24.05.2012 21:20
Ich finde es nicht verwerflich
euch danach zu fragen.
Ihr h
abt halt einen super support!
Ich finde die Frage nic [...]
Do, 24.05.2012 20:37
Ich wuerde da weniger auf eine
n "Gesellen" im Browser tippen
, sondern eher auf ein gehackt
es Script auf seiner Web [...]
Do, 24.05.2012 19:14
Och,
ich empfinde das noch al
s relativ neutral. Und so frag
t er halt einfach nach bei dir
.
