Auf einem System, das mit Hilfe von Vinum vollgespiegelte Dateisysteme hat, ist es wünschenswert, auch das Root-Dateisystem zu spiegeln. Solch eine Konfiguration ist allerdings weniger trivial als das Spiegeln eines gewöhnlichen Dateisystems, weil:
Das Root-Dateisystem in einer sehr frühen Phase des Bootvorgangs verfügbar sein muss, und damit auch die Vinum-Infrastruktur.
Das Volume, welches das Root-Dateisystem enthält, auch den Bootstrap und den Kernel enthält, die wiederum nur mit den systemeigenen Tools (zum Beispiel dem BIOS bei handelsüblichen PCs) gelesen werden können und meist nicht dazu gebracht werden können, Vinum zu verstehen.
Im folgenden Abschnitt wird der Begriff “Root-Volume” benutzt, um das Vinum-Volume zu beschreiben, welches das Root-Dateisystem enthält. Es ist eine gute Idee, für dieses Volume den Namen "root" zu benutzen, aber es ist in keiner Weise technisch nötig (Das folgende Beispiel geht allerdings davon aus, dass dies der Fall ist.).
Damit dies gelingt, müssen Sie folgende Aufgaben erledigen:
Vinum muss zum Zeitpunkt des Bootvorganges im Kernel zur Verfügung stehen. Deswegen ist die Methode zum Start von Vinum, die in Abschnitt 22.8.1.1 beschrieben wird, für diese Aufgabe nicht geeignet. Also muss auch der start_vinum-Parameter eigentlich nicht gesetzt werden, wenn man das folgende Setup einrichtet. Die erste Möglichkeit wäre es, Vinum statisch in den Kernel zu kompilieren, so dass es ständig verfügbar ist, was aber in der Regel nicht erwünscht ist. Ebenso gibt es die Möglichkeit /boot/loader (Abschnitt 13.3.3) das Vinum-Kernelmodul früh genug laden zu lassen (und zwar noch bevor der Kernel gestartet wird). Dies kann bewerkstelligt werden, indem die Zeile
geom_vinum_load="YES"
in die Datei /boot/loader.conf eingetragen wird.
Für Gvinum ist das oben beschriebene Prozedere alles, was Sie tun müssen, da der gesamte Startvorgang automatisch erledigt wird, sobald das Kernelmodul geladen wurde.
Da der aktuelle FreeBSD-Bootstrap nur 7,5 KB Code enthält und schon ohne Vinum die Aufgabe hat, bestimmte Dateien (wie /boot/loader) von einem UFS-Dateisystem zu lesen, ist es schier unmöglich, ihm auch noch die Interna von Vinum beizubringen, damit er die Vinum-Konfigurationsdaten auslesen und die Elemente eines Boot-Volumes selbst herausfinden könnte. Daher sind ein paar Tricks nötig, um dem Bootstrap-Code die Illusion einer Standard-"a"-Partition mit einem Root-Dateisystem vorzugaukeln.
Damit dies überhaupt möglich wird, müssen die folgenden Bedingungen für das Root-Dateisystem erfüllt sein:
Das Root-Volume darf weder gestriped noch RAID-5 sein.
Das Root-Volume darf nicht mehr als eine konkatenierte Subdisk pro Plexus enthalten.
Beachten Sie, dass es möglich und wünschenswert ist, mehrere Plexus zu haben, von denen jeder eine Kopie des Root-Dateisystems enthält. Der Bootstrap-Prozess wird hingegen nur einen dieser Plexus benutzen, um den Bootstrap und alle Dateien zu finden, bis der Kernel letztendlich das Root-Dateisystem selbst laden wird. Jede einzelne Subdisk innerhalb dieser Plexus wird dann ihre eigene Illusion der Partition "a" brauchen, damit das entsprechende Gerät bootbar wird. Es ist nicht unbedingt notwendig, dass sich jede dieser gefälschten "a"-Partitionen auf seinem Gerät an einem Ort befindet, der um den selben Wert verschoben ist wie auf den anderen Geräten, die Plexus des Root-Dateisystems enthalten. Um Unklarheiten zu verhindern, ist es jedoch eine gute Idee, die Vinum-Volumes so zu erstellen, dass die gespiegelten Geräte symmetrisch sind.
Damit diese "a"-Partitionen eingerichtet werden können, muss für alle Geräte, die Teil des Root-Dateisystems sind, folgendes getan werden:
Der Ort (Verschiebung vom Beginn des Gerätes) und die Größe der Subdisk, die Teil des Root-Volumes ist, muss untersucht werden:
# gvinum l -rv root
Beachten Sie, dass Vinum-Verschiebungen und -Größen in Bytes gemessen werden. Sie müssen deshalb durch 512 geteilt werden, um die Blockanzahl zu erhalten, wie sie das bsdlabel-Kommando verwendet.
Führen Sie den Befehl
# bsdlabel -e devname
für jedes Gerät, dass am Root-Volume beteiligt ist, aus. devname muss entweder der Name der Platte (wie da0), im Falle einer Platte ohne Slice-Tabelle oder der Name des Slices (wie ad0s1) sein.
Wenn es schon eine "a"-Partition auf dem Gerät (in der Regel wahrscheinlich ein Prä-Vinum-Root-Dateisystem) gibt, sollte diese umbenannt werden, damit sie weiterhin verfügbar bleibt (nur für den Fall). Sie wird aber nicht länger benutzt, um das System zu starten. Beachten Sie aber, dass aktive Partitionen (wie ein gemountetes Root-Dateisystem) nicht umbenannt werden können, sodass Sie entweder von einem “Fixit”-Medium booten müssen, oder aber mittels eines zweistufigen Prozesses (sofern Sie in einer gespiegelten Umgebung arbeiten) zuerst die Platte ändern, von der gerade nicht gebootet wurde.
Nun muss die Verschiebung der Vinum-Partition (sofern vorhanden) auf diesem Gerät mit der Veschiebung der entsprechenden Root-Volume-Subdisk addiert werden. Das Resultat wird der "offset"-Wert für die neue "a"-Partition. Der "size"-Wert für diese Partition kann entsprechend der Berechnung ermittelt werden. "fstype" sollte 4.2BSD sein. Die "fsize"-, "bsize"-, und "cpg"- Werte sollten entsprechend dem eigentlichen Dateisystem gewählt werden, obwohl sie in diesem Kontext ziemlich unwichtig sind.
Auf diese Art und Weise wird eine neue Partition "a" etabliert, die die Vinum-Partition auf diesem Gerät überschneidet. Beachte Sie, dass das bsdlabel-Kommando diese Überschneidung nur erlaubt, wenn die Partition richtig mit dem "vinum"-fstype markiert ist.
Das ist alles. Auf jedem Gerät befindet sich nun eine gefälschte "a"-Partition, die eine Kopie des Root-Volumes enthält. Es wird dringend empfohlen, das Resultat dieser Konfiguration zu überprüfen:
# fsck -n /dev/devnamea
Denken Sie stets daran, dass alle Dateien, die Kontrollinformationen enthalten, nun relativ zum Root-Dateisystem innerhalb des Vinum-Volumes sein müssen. Denn ein neu eingerichtetes Vinum-Root-Dateisystem ist möglicherweise inkompatibel zum gerade aktiven Root-Dateisystem. Deshalb müssen insbesondere die Dateien /etc/fstab und /boot/loader.conf überprüft werden.
Beim nächsten Systemstart sollte der Bootstrap die adäquaten Kontrollinformationen des neuen Vinum-basierten Root-Dateisystems automatisch herausfinden und entsprechend handeln. Am Ende des Kernel-Initialisierungsprozesses (nachdem alle Geräte angezeigt wurden) erhalten Sie bei einer erfolgreichen Konfiguration eine Nachricht ähnlich der folgenden:
Mounting root from ufs:/dev/gvinum/root
Nachdem das Vinum-Root-Volume eingerichtet wurde, könnte die Ausgabe von gvinum l -rv root bespielsweise so aussehen:
... Subdisk root.p0.s0: Size: 125829120 bytes (120 MB) State: up Plex root.p0 at offset 0 (0 B) Drive disk0 (/dev/da0h) at offset 135680 (132 kB) Subdisk root.p1.s0: Size: 125829120 bytes (120 MB) State: up Plex root.p1 at offset 0 (0 B) Drive disk1 (/dev/da1h) at offset 135680 (132 kB)
Wichtig ist hier insbesondere ist der Wert 135680 für die Verschiebung (relativ zur Partition /dev/da0h). Das entspricht beim Einsatz von bsdlabel 265 512-Byte-Plattenblöcken. Dieses Root-Volume ist ebenso 245760 512-Byte-Blöcke groß. /dev/da1h enthält die zweite Kopie dieses Root-Volumes und ist symmetrisch aufgebaut.
Das Bsdlabel für diese Geräte könnte so aussehen:
... 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 245760 281 4.2BSD 2048 16384 0 # (Cyl. 0*- 15*) c: 71771688 0 unused 0 0 # (Cyl. 0 - 4467*) h: 71771672 16 vinum # (Cyl. 0*- 4467*)
Wie man leicht feststellen kann, entspricht der Parameter "size" der gefälschten "a"-Partition dem ausgewiesenen Wert von oben, während der Parameter "offset" gleich der Summe der Verschiebung innerhalb der Vinum-Partition "h" und der Verschiebung innerhalb des Geräts (oder Slice) ist. Dies ist ein typischer Aufbau, der nötig ist, um die in Abschnitt 22.9.4.3 beschriebenen Probleme zu vermeiden. Die gesamte Partition "a" befindet sich in "h", die alle Vinum-Daten für dieses Gerät enthält.
Beachten Sie, dass in dem oben beschriebenen Beispiel das gesamte Gerät Vinum gewidmet ist und keine Prä-Vinum-Partition zurückgelassen wurde, da es sich im Beispiel um eine neu eingerichtete Platte handelt, die nur für die Vinum-Konfiguration bestimmt war.
Der folgende Abschnitt beschreibt einige bekannte Probleme und Fallstricke bei der Vinum-Konfiguration sowie deren Behebung.
Wenn aus irgendeinem Grund das System nicht mit dem Booten fortfährt, kann man den Bootstrap während der 10-Sekunden-Warnung durch Drücken der Leertaste unterbrechen. Die loader-Variablen (wie vinum.autostart) können mittels des show-Kommandos untersucht, und mit set oder unset geändert werden.
Wenn das einzige Problem das Fehlen des Vinum-Kernelmoduls in der Liste der automatisch zu ladenden Module ist, hilft ein einfaches load geom_vinum.
Danach können Sie den Bootvorgang mit boot -as
fortsetzen. Die Optionen -as fordern den Kernel auf,
nach dem zu mountenden Root-Dateisystem zu fragen (-a),
und den Bootvorgang im Single-User-Modus (-s) zu
beenden, in dem das Root-Dateisystem schon schreibgeschützt gemountet ist.
Auf diese Weise wird keine Dateninkonsistenz zwischen den Plexus riskiert, auch
wenn nur ein Plexus eines Multi-Plexus-Volumes gemountet wurde.
Beim Prompt, das nach einem Root-Dateisystem fragt, kann jedes Gerät angegeben werden, dass ein gültiges Root-Dateisystem hat. Wenn /etc/fstab richtig konfiguriert wurde, sollte die Vorgabe etwas wie ufs:/dev/gvinum/root sein. Eine typische Alternative würde etwas wie ufs:da0d sein, welches eine hypothetische Partition sein könnte, die ein Pre-Vinum-Root-Dateisystem enthält. Vorsicht sollte walten, wenn eine der alias "a"-Partitionen hier eingegeben wird, die eigentlich Referenzen auf die Subdisks des Vinum-Root-Dateisystems sind, da so nur ein Stück eines gespiegelten Root-Gerätes gemountet werden würde. Wenn das Dateisystem später zum Lesen und Schreiben gemountet werden soll, ist es nötig, die anderen Plexus des Vinum-Root-Volumes zu entfernen, weil diese Plexus andernfalls inkonsistente Daten enthalten würden.
Wenn das Laden von /boot/loader fehlschlägt, aber der primäre Bootstrap dennoch lädt (sichtbar an dem einzelnen Strich in der linken Spalte des Bildschirms gleich nachdem der Bootprozess startet), kann man versuchen, den primären Bootstrap an diesem Punkt durch Benutzen der Leertaste zu unterbrechen. Dies wird den Bootstrap in der zweiten Phase stoppen (siehe dazu auch Abschnitt 13.3.2). Hier kann nun der Versuch unternommen werden, von einer anderen Partition zu booten, wie beispielsweise dem vorhergehenden Root-Dateisystem, das von "a" verschoben wurde.
Diese Situation wird vorkommen, wenn der Bootstrap durch die Vinum-Installation zerstört worden ist. Unglücklicherweise lässt Vinum am Anfang seiner Partition nur 4 KB frei und schreibt dahinter seine Kopfinformationen. Allerdings benötigen Stufe-Eins- und -Zwei-Bootstraps plus dem dazwischen eingebetteten bsdlabel momentan 8 KB. Demzufolge wird die Vinum-Installation, wenn die Vinum-Partition mit der Verschiebung 0 (innerhalb eines Slice oder einer Platte, die zum Start bestimmt waren) eingerichtet wurde, den Bootstrap zerstören.
Analog wird eine anschließende Reinstallation eines Bootstrap (zum Beispiel durch Booten eines “Fixit”-Mediums) mit bsdlabel -B, wie in Abschnitt 13.3.2 beschrieben, den Vinum-Kopf zerstören und Vinum wird seine Platte(n) nicht mehr finden können. Obwohl keine eigentlichen Vinum-Konfigurationsdaten oder Daten in den Vinum-Volumes zerstört werden und es möglich wäre, alle Daten wiederherzustellen, indem die exakt gleichen Vinum-Konfigurationsdaten noch einmal eingegeben werden, bleibt die Situation schwer zu bereinigen, da es nötig ist, die gesamte Vinum-Partition um mindestens 4 KB nach hinten zu verschieben, damit Bootstrap und Vinum-Kopf nicht mehr kollidieren.
| Zurück | Zum Anfang | Weiter |
| Vinum konfigurieren | Nach oben | Virtualisierung |
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<[email protected]>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <[email protected]>.