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, „Automatische Inbetriebnahme“ 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, „Phase drei, /boot/loader
“) das Vinum-Kernelmodul
früh genug laden zu lassen (und zwar noch bevor
der Kernel gestartet wird). Dies kann bewerkstelligt
werden, indem die Zeile
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/devname
a
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:
Nachdem das Vinum-Root-Volume eingerichtet wurde,
könnte die Ausgabe von gvinum l -rv root
bespielsweise so aussehen:
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:
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, „Nichts bootet, der Bootstrap hängt sich auf“ 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, „Phase Eins, /boot/boot1
und Phase Zwei,
/boot/boot2
“). 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, „Phase Eins, /boot/boot1
und Phase Zwei,
/boot/boot2
“ 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.
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an
<de-bsd-translators@de.FreeBSD.org>.