1440 lines
58 KiB
XML
1440 lines
58 KiB
XML
<?xml version="1.0" encoding="iso-8859-1" standalone="no"?>
|
|
<!--
|
|
The Vinum Volume Manager
|
|
By Greg Lehey (grog at lemis dot com)
|
|
|
|
Added to the Handbook by Hiten Pandya <hmp@FreeBSD.org>
|
|
and Tom Rhodes <trhodes@FreeBSD.org>
|
|
|
|
The FreeBSD Documentation Project
|
|
The FreeBSD German Documentation Project
|
|
|
|
$FreeBSD$
|
|
$FreeBSDde: de-docproj/books/handbook/vinum/chapter.sgml,v 1.19 2011/01/30 13:27:20 bcr Exp $
|
|
basiert auf: 1.49
|
|
-->
|
|
|
|
<chapter id="vinum-vinum">
|
|
<chapterinfo>
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Greg</firstname>
|
|
<surname>Lehey</surname>
|
|
<contrib>Ursprünglich geschrieben von </contrib>
|
|
</author>
|
|
</authorgroup>
|
|
<authorgroup>
|
|
<author>
|
|
<firstname>Johann</firstname>
|
|
<surname>Kois</surname>
|
|
<contrib>Übersetzt von </contrib>
|
|
</author>
|
|
<author>
|
|
<firstname>Kay</firstname>
|
|
<surname>Abendroth</surname>
|
|
</author>
|
|
</authorgroup>
|
|
</chapterinfo>
|
|
|
|
<title>Der Vinum Volume Manager</title>
|
|
|
|
<sect1 id="vinum-synopsis">
|
|
<title>Übersicht</title>
|
|
|
|
|
|
<para>Egal, über welche und wieviele Festplatten Ihr System
|
|
auch verfügt, immer wieder werden Sie mit den folgenden
|
|
Problemen konfrontiert:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Ihre Platten sind zu klein.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Sie sind zu langsam.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Ihre Platten sind unzuverlässig.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Um derartige Probleme zu lösen, wurden verschiedene
|
|
Methoden entwickelt. Eine Möglichkeit bietet der
|
|
Einsatz von mehreren, manchmal auch redundant ausgelegten
|
|
Platten. Zusätzlich zur Unterstützung verschiedener
|
|
Erweiterungskarten und Controller für Hardware-RAID-Systeme
|
|
enthält das &os;-Basissystem auch den Vinum
|
|
Volume Manager, einen Blockgerätetreiber, der die
|
|
Einrichtung virtueller Platten unterstützt. Bei
|
|
<emphasis>Vinum</emphasis> handelt es sich um einen
|
|
sogenannten <emphasis>Volume Manager</emphasis>, einen
|
|
virtuellen Plattentreiber, der obige drei Probleme löst.
|
|
Vinum bietet Ihnen größere Flexibilität,
|
|
Leistung und Zuverlässigkeit als die klassische
|
|
Datenspeicherung auf einzelne Festplatten. Dazu unterstützt
|
|
Vinum RAID-0, RAID-1 und RAID-5 (sowohl einzeln als auch in
|
|
Kombination).</para>
|
|
|
|
<para>Dieses Kapitel bietet Ihnen einen Überblick über
|
|
potentielle Probleme der klassischen Datenspeicherung auf
|
|
Festplatten sowie eine Einführung in den Vinum
|
|
Volume Manager.</para>
|
|
|
|
<note>
|
|
<para>Für &os; 5.X wurde Vinum überarbeitet und
|
|
an die GEOM-Architektur (<xref linkend="GEOM"/>) angepasst,
|
|
wobei die ursprünglichen Ideeen und Begriffe sowie die
|
|
auf der Platte benötigten Metadaten beibehalten wurden.
|
|
Die überarbeitete Version wird als
|
|
<emphasis>gvinum</emphasis> (für
|
|
<emphasis>GEOM-Vinum</emphasis>) bezeichnet. Die folgenden
|
|
Ausführungen verwenden den Begriff
|
|
<emphasis>Vinum</emphasis> als abstrakten Namen, unabhängig
|
|
davon, welche Variante implementiert wurde. Sämtliche
|
|
Befehlsaufrufe erfolgen über <command>gvinum</command>,
|
|
welches nun das Kernelmodul <filename>geom_vinum.ko</filename>
|
|
(statt <filename>vinum.ko</filename>) benötigt. Analog
|
|
finden sich alle Gerätedateien nun unter <filename
|
|
class="directory">/dev/gvinum</filename> statt unter <filename
|
|
class="directory">/dev/vinum</filename>. Seit &os; 6.x ist die
|
|
alte Vinum-Implementierung nicht mehr im Basissystem enthalten.</para>
|
|
</note>
|
|
</sect1>
|
|
|
|
<sect1 id="vinum-intro">
|
|
<title>Ihre Platten sind zu klein.</title>
|
|
|
|
<indexterm><primary>Vinum</primary></indexterm>
|
|
<indexterm>
|
|
<primary>RAID</primary>
|
|
<secondary>Software</secondary>
|
|
</indexterm>
|
|
|
|
<para>Festplatten werden zwar immer größer, parallel
|
|
dazu steigt aber auch die Größe der zu speichernden
|
|
Daten an. Es kann also nach wie vor vorkommen, dass Sie ein
|
|
Dateisystem benötigen, welches die Größe Ihrer
|
|
Platten übersteigt. Zwar ist dieses Problem nicht mehr
|
|
so akut wie noch vor einigen Jahren, aber es existiert nach
|
|
wie vor. Einige Systeme lösen dieses Problem durch die
|
|
Erzeugung eines abstrakten Gerätes, das seine Daten auf
|
|
mehreren Platten speichert.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="vinum-access-bottlenecks">
|
|
<title>Mögliche Engpässe</title>
|
|
|
|
<para>Moderne Systeme müssen häufig parallel auf
|
|
Daten zugreifen. Große FTP- und HTTP-Server
|
|
können beispielsweise Tausende von parallelen Sitzungen
|
|
verwalten und haben mehrere 100 MBit/s-Verbindungen
|
|
zur Außenwelt. Diese Bandbreite überschreitet
|
|
die durchschnittliche Transferrate der meisten Platten
|
|
bei weitem.</para>
|
|
|
|
<para>Aktuelle Plattenlaufwerke können Daten mit bis zu
|
|
70 MB/s sequentiell übertragen, wobei dieser Wert
|
|
in einer Umgebung, in der viele unabhängige Prozesse auf
|
|
eine gemeinsame Platte zugreifen, die jeweils nur einen
|
|
Bruchteil dieses Wertes erreichen, von geringer Aussagekraft
|
|
ist. In solchen Fällen ist es interessanter, das Problem
|
|
vom Blickwinkel des Platten-Subsystems aus zu betrachten.
|
|
Der wichtigste Parameter ist dabei die Last, die eine
|
|
Übertragung auf dem Subsystem verursacht. Unter Last
|
|
versteht man dabei die Zeit, in der die Platte mit der
|
|
Übertragung der Daten beschäftigt ist.</para>
|
|
|
|
<para>Bei jedem Plattenzugriff muss das Laufwerk zuerst die
|
|
Köpfe positionieren und auf den ersten Sektor warten, bis
|
|
er den Lesekopf passiert. Dann wird die Übertragung
|
|
gestartet. Diese Aktionen können als atomar betrachtet
|
|
werden, da es keinen Sinn macht, diese zu unterbrechen.</para>
|
|
|
|
<para><anchor id="vinum-latency"/>Nehmen wir beispielsweise an,
|
|
dass wir 10 kB transferieren wollen. Aktuelle
|
|
hochperformante Platten können die Köpfe im Durchschnitt
|
|
in 3,5 ms positionieren und drehen sich mit maximal
|
|
15.000 U/min. Daher beträgt die durchschnittliche
|
|
Rotationslatenz (eine halbe Umdrehung) 2 ms.
|
|
Bei einer Transferrate von 70 MB/s dauert die eigentliche
|
|
Übertragung von 10 kB etwa 150 μs, fast
|
|
nichts im Vergleich zur Positionierungszeit. In einem solchen
|
|
Fall beträgt die effektive Transferrate nur etwas mehr
|
|
als 1 MB/s. Die Tranferrate ist also stark von der
|
|
Größe der zu tranferierenden Daten
|
|
abhängig.</para>
|
|
|
|
<para>Die traditionelle und offensichtliche Lösung zur
|
|
Beseitigung dieses Flaschenhalses sind <quote>mehr
|
|
Spindeln</quote>. Statt einer einzigen großen Platte werden
|
|
mehrere kleinere Platten mit demselben Gesamtspeicherplatz
|
|
benutzt. Jede Platte ist in der Lage, unabhängig zu
|
|
positionieren und zu transferieren, weshalb der effektive
|
|
Durchsatz um einen Faktor nahe der Zahl der eingesetzten Platten
|
|
steigt.</para>
|
|
|
|
<para>Obwohl die Platten Daten parallel transferieren können,
|
|
ist es nicht möglich, Anfragen gleichmäßig auf
|
|
die einzelnen Platten zu verteilen. Daher wird die Last auf
|
|
bestimmten Laufwerken immer höher sein als auf anderen
|
|
Laufwerken. Daraus ergibt sich auch, dass die exakte Verbesserung
|
|
des Datendurchsatzes immer kleiner ist als die Anzahl der
|
|
involvierten Platten.</para>
|
|
|
|
<indexterm>
|
|
<primary>Plattenkonkatenation</primary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary>Vinum</primary>
|
|
<secondary>Konkatenation</secondary>
|
|
</indexterm>
|
|
|
|
<para>Die gleichmäßige Verteilung der Last auf die einzelnen
|
|
Platten ist stark abhängig von der Art, wie die Daten auf die
|
|
Laufwerke aufgeteilt werden. In den folgenden Ausführungen
|
|
wird eine Platte als eine große Anzahl von Datensektoren
|
|
dargestellt, die durch Zahlen adressierbar sind (ähnlich
|
|
den Seiten eines Buches). Die naheliegendste Methode ist es,
|
|
die virtuelle Platte (wieder analog den Seiten eines Buches)
|
|
in Gruppen aufeinanderfolgender Sektoren zu unterteilen, die
|
|
jeweils der Größe der einzelnen physischen Platten
|
|
entsprechen. Diese Vorgehensweise wird als
|
|
<emphasis>Konkatenation</emphasis> bezeichnet und hat den
|
|
Vorteil, dass die Platten keine spezielle
|
|
Größenbeziehung haben müssen. Sie funktioniert
|
|
gut, solange der Zugriff gleichmäßig auf den
|
|
Adressraum der virtuellen Platte verteilt wird. Wenn sich der
|
|
Zugriff allerdings auf einen kleinen Bereich konzentriert, ist die
|
|
Verbesserung vernachlässigbar klein.
|
|
<xref linkend="vinum-concat"/> verdeutlicht die Verteilung der
|
|
Speichereinheiten in einer konkatenierten Anordnung.</para>
|
|
|
|
<para>
|
|
<figure id="vinum-concat">
|
|
<title>Konkatenierte Anordnung</title>
|
|
<graphic fileref="vinum/vinum-concat"/>
|
|
</figure>
|
|
</para>
|
|
|
|
<indexterm>
|
|
<primary>Striping von Platten</primary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary>Vinum</primary>
|
|
<secondary>Striping</secondary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary>RAID</primary>
|
|
</indexterm>
|
|
|
|
<para>Ein alternatives Mapping unterteilt den Adressraum in
|
|
kleinere, gleich große Komponenten und speichert diese
|
|
sequentiell auf verschiedenen Geräten. Zum Beispiel werden
|
|
die ersten 256 Sektoren auf der ersten Platte, die nächsten
|
|
256 Sektoren auf der zweiten Platte gespeichert und so
|
|
weiter. Nachdem die letzte Platte beschrieben wurde, wird dieser
|
|
Vorgang solange wiederholt, bis die Platten voll sind. Dieses
|
|
Mapping nennt man <emphasis>Striping</emphasis> oder
|
|
<acronym>RAID-0</acronym>.
|
|
<footnote>
|
|
<para><acronym>RAID</acronym> steht für <emphasis>Redundant
|
|
Array of Inexpensive Disks</emphasis> und bietet verschiedene
|
|
Formen der Fehlertorleranz, obwohl der letzte Begriff etwas
|
|
irreführend ist, da RAID keine Redundanz bietet.</para>
|
|
</footnote></para>
|
|
|
|
<para>Striping erfordert einen etwas größeren Aufwand,
|
|
um die Daten zu
|
|
lokalisieren, und kann zusätzliche E/A-Last verursachen,
|
|
wenn eine Übertragung über mehrere Platten verteilt
|
|
ist. Auf der anderen Seite erlaubt es aber eine
|
|
gleichmäßigere Verteilung der Last auf die einzelnen
|
|
Platten. <xref linkend="vinum-striped"/> veranschaulicht
|
|
die Abfolge, in der Speichereinheiten in einer striped-Anordnung
|
|
alloziert werden.</para>
|
|
|
|
<para>
|
|
<figure id="vinum-striped">
|
|
<title>Striped-Anordnung</title>
|
|
<graphic fileref="vinum/vinum-striped"/>
|
|
</figure>
|
|
</para>
|
|
</sect1>
|
|
|
|
<sect1 id="vinum-data-integrity">
|
|
<title>Datenintegrität</title>
|
|
|
|
<para>Das dritte Problem, welches aktuelle Platten haben, ist ihre
|
|
Unzuverlässigkeit. Obwohl sich die Zuverlässigkeit
|
|
von Festplatten in den letzten Jahren stark verbessert hat,
|
|
handelt es sich bei ihnen nach wie vor um die Komponente eines
|
|
Servers, die am ehesten ausfällt. Fällt eine
|
|
Festplatte aus, können die Folgen katastrophal sein: Es
|
|
kann Tage dauern, bis eine Platte ersetzt und alle Daten
|
|
wiederhergestellt sind.</para>
|
|
|
|
<indexterm>
|
|
<primary>disk mirroring</primary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary>Vinum</primary>
|
|
<secondary>Spiegelung</secondary>
|
|
</indexterm>
|
|
<indexterm>
|
|
<primary>RAID-1</primary>
|
|
</indexterm>
|
|
|
|
<para>Die traditionelle Art, dieses Problem anzugehen, war es,
|
|
Daten zu <emphasis>spiegeln</emphasis>, also zwei Kopien der
|
|
Daten auf getrennten Platten zu verwahren. Diese Technik wird
|
|
auch als <acronym>RAID Level 1</acronym> oder
|
|
<acronym>RAID-1</acronym> bezeichnet. Jeder Schreibzugriff
|
|
findet auf beiden Datenträgern statt. Ein Lesezugriff
|
|
kann daher von beiden Laufwerken erfolgen, sodass beim Ausfall
|
|
eines Laufwerks die Daten immer noch auf dem anderen
|
|
Laufwerk verfügbar sind.</para>
|
|
|
|
<para>Spiegeln verursacht allerdings zwei Probleme:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Es verursacht höhere Kosten, da doppelt so viel
|
|
Plattenspeicher wie bei einer nicht-redundanten
|
|
Lösung benötigt wird.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Die Gesamtleistung des Systems sinkt, da
|
|
Schreibzugriffe auf beiden Laufwerken ausgeführt
|
|
werden müssen, daher wird im Vergleich zu einem
|
|
nicht gespiegelten Datenträger die doppelte
|
|
Bandbreite benötigt. Lesezugriffe hingegen sind
|
|
davon nicht betroffen, es sieht sogar so aus, als
|
|
würden diese schneller ausgeführt.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<indexterm><primary>RAID-5</primary></indexterm>
|
|
|
|
<para>Eine alternative Lösung ist
|
|
<emphasis>Parity</emphasis>, das in den
|
|
<acronym>RAID</acronym>-Leveln 2, 3, 4 und 5
|
|
implementiert ist. Von diesen ist <acronym>RAID-5</acronym>
|
|
der interessanteste. So wie in VINUM implementiert, ist es
|
|
eine Variante einer gestripten Anordung, welche einen Block
|
|
jedes Stripes als Paritätsblock für einen der anderen
|
|
Blöcke verwendet. Wie in <acronym>RAID-5</acronym>
|
|
vorgeschrieben, ist die Position dieses Paritätsblockes
|
|
auf jedem Stripe unterschiedlich. Die Nummern in den
|
|
Datenblöcken geben die relativen Blocknummern an.</para>
|
|
|
|
<para>
|
|
<figure id="vinum-raid5-org">
|
|
<title>RAID-5 Aufbau</title>
|
|
<graphic fileref="vinum/vinum-raid5-org"/>
|
|
</figure>
|
|
</para>
|
|
|
|
<para>Im Vergleich zur Spiegelung hat RAID-5 den Vorteil, dass
|
|
es signifikant weniger Speicherplatz benötigt.
|
|
Lesezugriffe sind vergleichbar schnell mit jenen bei einem
|
|
Striped-Aufbau, aber Schreibzugriffe sind deutlich langsamer
|
|
(etwa 25% der Lesegeschwindigkeit). Wenn eine Platte
|
|
ausfällt, kann das Array in einem "schwachen" Modus
|
|
weiterarbeiten: Ein Lesezugriff auf eine der übrigen
|
|
erreichbaren Platten wird normal ausgeführt, ein
|
|
Lesezugriff auf die ausgefallene Platte muss aber
|
|
zunächst mit dem zugehörigen Block aller
|
|
verbleibender Platten rückberechnet werden.</para>
|
|
</sect1>
|
|
|
|
<sect1 id="vinum-objects">
|
|
<title>Vinum-Objekte</title>
|
|
<para>Um die in den vorigen Abschnitte besprochenen Probleme zu
|
|
lösen, verwendet Vinum eine vierstufige
|
|
Objekthierarchie:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Das auffälligste Objekt ist die virtuelle Platte,
|
|
die <emphasis>Volume</emphasis> genannt wird. Volumes
|
|
haben im Wesentlichen die gleichen Eigenschaften wie ein
|
|
&unix;-Laufwerk, obwohl es ein paar kleine Unterschiede
|
|
gibt. So existieren für Volumes beispielsweise keine
|
|
Größenbeschränkungen.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Volumes bestehen aus einem oder mehreren
|
|
<emphasis>Plexus</emphasis>,
|
|
von denen jeder den gesamten Adressraum eines
|
|
Datenträgers repräsentiert. Diese Hierarchieebene
|
|
ist für die benötigte Redundanz der Daten
|
|
erforderlich. Stellen Sie sich die Plexus als
|
|
eigenständige Platten in einem gespiegelten
|
|
Array vor, von denen jede die gleichen Daten
|
|
enthält.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Da Vinum im &unix;-Plattenspeicher-Framework arbeitet,
|
|
wäre es möglich, als Grundbaustein für
|
|
Multiplatten-Plexus &unix;-Partitionen zu verwenden. In
|
|
der Praxis ist dieser Ansatz aber zu unflexibel, da
|
|
&unix;-Platten nur eine begrenzte Anzahl von Partitionen
|
|
haben können. Daher unterteilt Vinum stattdessen
|
|
eine einzige &unix;-Partition (die
|
|
<emphasis>Platte</emphasis>) in zusammenhängende
|
|
Bereiche, die als <emphasis>Subdisks</emphasis> bezeichnet
|
|
werden und als Grundbausteine für einen Plexus
|
|
benutzt werden.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Subdisks befinden sich auf
|
|
Vinum-<emphasis>Platten</emphasis>, eigentlich
|
|
&unix;-Partitionen. Vinum-Platten können eine
|
|
beliebige Anzahl von Subdisks haben und den gesamten
|
|
Speicher der Platte mit Ausnahme eines kleinen Bereiches
|
|
am Anfang der Platte (welcher zur Speicherung von
|
|
Konfigurations- und Statusinformationen verwenden wird)
|
|
verwenden.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Der folgende Abschnitt beschreibt, wie diese Objekte
|
|
die von Vinum benötigten Funktionen zur
|
|
Verfügung stellen.</para>
|
|
|
|
<sect2>
|
|
<title>Überlegungungen zur Größe eines Volumes</title>
|
|
|
|
<para>Plexus können mehrere Subdisks beinhalten, die
|
|
über alle Platten der Vinum-Konfiguration verteilt sind.
|
|
Daraus folgt, dass die Größe einer Platte nicht die
|
|
Größe eines Plexus (und damit eines Volumes)
|
|
limitiert.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Redundante Datenspeicherung</title>
|
|
|
|
<para>Vinum implementiert die Datenspiegelung, indem es ein
|
|
Volume auf mehrere Plexus verteilt. Jeder Plexus ist
|
|
dabei die Repräsentation der Daten eines Volumes.
|
|
Ein Volume kann aus bis zu acht Plexus bestehen.</para>
|
|
|
|
<para>Obwohl ein Plexus die gesamten Daten eines Volumes
|
|
repräsentiert, ist es möglich, dass Teile der
|
|
Repräsentation physisch fehlen, entweder aufgrund des
|
|
Designs (etwa durch nicht definierte Subdisks für Teile
|
|
des Plexus) oder durch Zufall (als ein Ergebnis eines
|
|
Plattenfehlers). Solange wenigstens ein Plexus die gesamten
|
|
Daten für den kompletten Adressbereich des Volumes zur
|
|
Verfügung stellen kann, ist das Volume voll
|
|
funktionsfähig.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Überlegungen zur Leistung</title>
|
|
|
|
<para>Sowohl Konkatenation als auch Striping werden von Vinum
|
|
auf der Plexus-Ebene realisiert:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Ein <emphasis>konkatenierter Plexus</emphasis> benutzt
|
|
abwechselnd den Adressraum jeder Subdisk.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Ein <emphasis>gestripter Plexus</emphasis> striped die
|
|
Daten über jede Subdisk. Die Subdisks müssen alle
|
|
die gleiche Größe haben, und es muss mindestens
|
|
zwei Subdisks in Reihenfolge geben, um ihn von einem
|
|
konkatenierten Plexus unterscheiden zu können.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Wie ist ein Plexus aufgebaut?</title>
|
|
|
|
<para>Die Version von Vinum, welche von &os;-&rel.current;
|
|
bereitgestellt wird, implementiert zwei Arten von Plexus:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Konkatenierte Plexus sind die flexibelsten: Sie
|
|
können aus einer beliebigen Anzahl von Subdisks
|
|
unterschiedlicher Größe bestehen. Der Plexus
|
|
kann erweitert werden, indem man zusätzliche Subdisks
|
|
hinzufügt. Sie brauchen weniger
|
|
<acronym>CPU</acronym>-Zeit als gestripte Plexus, obwohl
|
|
der Unterschied des <acronym>CPU</acronym>-Overheads nicht
|
|
messbar ist. Auf der anderen Seite sind sie aber sehr
|
|
anfällig für das Entstehen von "hot spots", wobei
|
|
eine Platte sehr aktiv ist, andere hingegen nahezu ungenutzt
|
|
sind.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Der größte Vorteil eines gestripten
|
|
Plexus (<acronym>RAID-0</acronym>) ist die Verringerung von
|
|
"hot spots". Dies wird durch die Auswahl eines Stripes
|
|
optimaler Größe (etwa 256 kB) erreicht,
|
|
wodurch die Last gleichmäßig auf die Platten
|
|
verteilt werden kann. Nachteile dieser Vorgehensweise sind
|
|
ein (geringfügig) komplexerer Code sowie einige
|
|
Restriktionen für die Subdisks: Diese müssen alle
|
|
die gleiche Größe haben, und das Erweitern eines
|
|
Plexus durch das Hinzufügen neuer Subdisks ist so
|
|
kompliziert, dass es von Vinum derzeit nicht
|
|
unterstützt wird. Vinum fordert noch eine weitere
|
|
triviale Beschränkung: Ein gestripter Plexus muss
|
|
aus mindestens zwei Subdisks bestehen, da er ansonsten nicht
|
|
von einem konkatenierten Plexus unterscheidbar ist.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para><xref linkend="vinum-comparison"/> fasst die Vor- und
|
|
Nachteile jedes Plexus-Aufbaus zusammen.</para>
|
|
|
|
<table id="vinum-comparison" frame="none">
|
|
<title>Vinum-Plexus - Aufbau</title>
|
|
|
|
<tgroup cols="5">
|
|
<thead>
|
|
<row>
|
|
<entry>Plexus-Typ</entry>
|
|
<entry>Minimum an Subdisks?</entry>
|
|
<entry>Kann Subdisks hinzufügen?</entry>
|
|
<entry>Müssen die gleiche Größe
|
|
haben</entry>
|
|
<entry>Applikation</entry>
|
|
</row>
|
|
</thead>
|
|
|
|
<tbody>
|
|
<row>
|
|
<entry>konkateniert</entry>
|
|
<entry>1</entry>
|
|
<entry>ja</entry>
|
|
<entry>nein</entry>
|
|
<entry>Großer Datenspeicher mit maximaler
|
|
Platzierungsflexibilität und moderater
|
|
Leistung</entry>
|
|
</row>
|
|
|
|
<row>
|
|
<entry>gestriped</entry>
|
|
<entry>2</entry>
|
|
<entry>nein</entry>
|
|
<entry>ja</entry>
|
|
<entry>Hohe Leistung in Kombination mit
|
|
gleichzeitigem Zugriff</entry>
|
|
</row>
|
|
</tbody>
|
|
</tgroup>
|
|
</table>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="vinum-examples">
|
|
<title>Einige Beispiele</title>
|
|
|
|
<para>Vinum verwaltet eine
|
|
<emphasis>Konfigurationsdatenbank</emphasis> für alle
|
|
einem individuellen System bekannten Objekte. Zu Beginn
|
|
erzeugt ein Benutzer mit &man.gvinum.8;
|
|
eine Konfigurationsdatenbank aus einer oder mehreren
|
|
Konfigurationsdateien. Vinum speichert danach eine Kopie der
|
|
Konfigurationsdatenbank in jedem von ihm kontrollierten
|
|
Slice (von Vinum als <emphasis>Device</emphasis>
|
|
bezeichnet). Da die Datenbank bei jedem Statuswechsel
|
|
aktualisiert wird, kann nach einem Neustart der Status
|
|
jedes Vinum-Objekts exakt wiederhergestellt werden.</para>
|
|
|
|
<sect2>
|
|
<title>Die Konfigurationsdatei</title>
|
|
|
|
<para>Die Konfigurationsdatei beschreibt individuelle
|
|
Vinum-Objekte. Die Beschreibung eines einfachen Volumes
|
|
könnte beispielsweise so aussehen:</para>
|
|
|
|
<programlisting>
|
|
drive a device /dev/da3h
|
|
volume myvol
|
|
plex org concat
|
|
sd length 512m drive a</programlisting>
|
|
|
|
<para>Diese Datei beschreibt vier Vinum-Objekte:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Die <emphasis>drive</emphasis>-Zeile beschreibt eine
|
|
Plattenpartition (<emphasis>drive</emphasis>) sowie ihre
|
|
Position in Bezug auf die darunter liegende Hardware.
|
|
Die Partition hat dabei den symbolischen Namen
|
|
<emphasis>a</emphasis>. Diese Trennung von symbolischen
|
|
Namen und Gerätenamen erlaubt es, die Position von
|
|
Platten zu ändern, ohne dass es zu Problemen
|
|
kommt.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Die <emphasis>volume</emphasis>-Zeile beschreibt ein
|
|
Volume. Dafür wird nur ein einziges Attribut, der
|
|
Name des Volumes, benötigt. In unserem Fall hat das
|
|
Volume den Namen <emphasis>myvol</emphasis>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Die <emphasis>plex</emphasis>-Zeile definiert einen
|
|
Plexus. Auch hier wird nur ein Parameter, und zwar die
|
|
Art des Aufbau, benötigt (in unserem Fall
|
|
<emphasis>concat</emphasis>). Es wird kein Name
|
|
benötigt, das System generiert automatisch einen
|
|
Namen aus dem Volume-Namen und dem Suffix
|
|
<emphasis>.p</emphasis><emphasis>x</emphasis> wobei
|
|
<emphasis>x</emphasis> die Nummer des Plexus innerhalb
|
|
des Volumes angibt. So wird dieser Plexus den Namen
|
|
<emphasis>myvol.p0</emphasis> erhalten.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Die <emphasis>sd</emphasis>-Zeile beschreibt eine
|
|
Subdisk. Um eine Subdisk einzurichten, müssen Sie
|
|
zumindest den Namen der Platte, auf der Sie die
|
|
Subdisk anlegen wollen, sowie die Größe der
|
|
Subdisk angeben. Analog zur Definition eines Plexus wird
|
|
auch hier kein Name benötigt: Das System weist
|
|
automatisch Namen zu, die aus dem Namen des Plexus und
|
|
dem Suffix <emphasis>.s</emphasis><emphasis>x</emphasis>
|
|
gebildet werden, wobei <emphasis>x</emphasis> die Nummer
|
|
der Subdisk innerhalb des Plexus ist. Folglich gibt
|
|
Vinum dieser Subdisk den Namen
|
|
<emphasis>myvol.p0.s0</emphasis>.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Nach dem Verarbeiten dieser Datei erzeugt &man.gvinum.8;
|
|
die folgende Ausgabe:</para>
|
|
|
|
<programlisting width="97">
|
|
&prompt.root; gvinum -> <userinput>create config1</userinput>
|
|
Configuration summary
|
|
Drives: 1 (4 configured)
|
|
Volumes: 1 (4 configured)
|
|
Plexes: 1 (8 configured)
|
|
Subdisks: 1 (16 configured)
|
|
|
|
D a State: up Device /dev/da3h Avail: 2061/2573 MB (80%)
|
|
|
|
V myvol State: up Plexes: 1 Size: 512 MB
|
|
|
|
P myvol.p0 C State: up Subdisks: 1 Size: 512 MB
|
|
|
|
S myvol.p0.s0 State: up PO: 0 B Size: 512 MB</programlisting>
|
|
|
|
<para>Diese Ausgabe entspricht dem verkürzten
|
|
Ausgabeformat von &man.gvinum.8; und wird in
|
|
<xref linkend="vinum-simple-vol"/> grafisch dargestellt.</para>
|
|
|
|
<para>
|
|
<figure id="vinum-simple-vol">
|
|
<title>Ein einfaches Vinum-Volume</title>
|
|
<graphic fileref="vinum/vinum-simple-vol"/>
|
|
</figure>
|
|
</para>
|
|
|
|
<para>Dieses und die folgenden Beispiele zeigen jeweils ein
|
|
Volume, welches die Plexus enthält, die wiederum die
|
|
Subdisk enthalten. In diesem trivialen Beispiel enthält
|
|
das Volume nur einen Plexus, der wiederum nur aus einer
|
|
Subdisk besteht.</para>
|
|
|
|
<para>Eine solche Konfiguration hätte allerdings keinen
|
|
Vorteil gegenüber einer konventionellen Plattenpartion.
|
|
Das Volume enthält nur einen einzigen Plexus, daher
|
|
gibt es keine redundante Datenspeicherung. Da der Plexus
|
|
außerdem nur eine einzige Subdisk enthält,
|
|
unterscheidet sich auch die Speicherzuweisung nicht von der
|
|
einer konventionellen Plattenpartition. Die folgenden
|
|
Abschnitte beschreiben daher verschiedene interessantere
|
|
Konfigurationen.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Verbesserte Ausfallsicherheit durch Spiegelung</title>
|
|
|
|
<para>Die Ausfallsicherheit eines Volumes kann durch
|
|
Spiegelung der Daten erhöht werden. Beim Anlegen eines
|
|
gespiegelten Volumes ist es wichtig, die Subdisks jedes
|
|
Plexus auf verschiedene Platten zu verteilen, damit ein
|
|
Plattenausfall nicht beide Plexus unbrauchbar macht. Die
|
|
folgende Konfiguration spiegelt ein Volume:</para>
|
|
|
|
<programlisting>
|
|
drive b device /dev/da4h
|
|
volume mirror
|
|
plex org concat
|
|
sd length 512m drive a
|
|
plex org concat
|
|
sd length 512m drive b</programlisting>
|
|
|
|
<para>Bei diesem Beispiel war es nicht nötig, noch einmal
|
|
eine Platte <emphasis>a</emphasis> zu spezifizieren, da
|
|
Vinum die Übersicht über alle Objekte und seine
|
|
Konfigurationsdatenbank behält. Nach dem Abarbeiten
|
|
dieser Definition sieht die Konfiguration wie folgt aus:</para>
|
|
|
|
<programlisting width="97">
|
|
Drives: 2 (4 configured)
|
|
Volumes: 2 (4 configured)
|
|
Plexes: 3 (8 configured)
|
|
Subdisks: 3 (16 configured)
|
|
|
|
D a State: up Device /dev/da3h Avail: 1549/2573 MB (60%)
|
|
D b State: up Device /dev/da4h Avail: 2061/2573 MB (80%)
|
|
|
|
V myvol State: up Plexes: 1 Size: 512 MB
|
|
V mirror State: up Plexes: 2 Size: 512 MB
|
|
|
|
P myvol.p0 C State: up Subdisks: 1 Size: 512 MB
|
|
P mirror.p0 C State: up Subdisks: 1 Size: 512 MB
|
|
P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB
|
|
|
|
S myvol.p0.s0 State: up PO: 0 B Size: 512 MB
|
|
S mirror.p0.s0 State: up PO: 0 B Size: 512 MB
|
|
S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB</programlisting>
|
|
|
|
<para><xref linkend="vinum-mirrored-vol"/> stellt diese Struktur
|
|
grafisch dar.</para>
|
|
|
|
<para>
|
|
<figure id="vinum-mirrored-vol">
|
|
<title>Ein gespiegeltes Vinum Volume</title>
|
|
<graphic fileref="vinum/vinum-mirrored-vol"/>
|
|
</figure>
|
|
</para>
|
|
|
|
<para>In diesem Beispiel enthält jeder Plexus die vollen
|
|
512 MB des Adressraumes. Wie im vorangegangenen Beispiel
|
|
enthält jeder Plexus nur eine Subdisk.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Die Leistung optimieren</title>
|
|
|
|
<para>Das gespiegelte Volume des letzten Beispieles ist
|
|
resistenter gegenüber Fehlern als ein ungespiegeltes
|
|
Volume, seine Leistung ist hingegen schlechter, da jeder
|
|
Schreibzugriff auf das Volume einen Schreibzugriff auf beide
|
|
Platten erfordert und damit mehr der insgesamt verfügbaren
|
|
Datentransferrate benötigt. Steht also die optimale
|
|
Leistung im Vordergrund, muss anders vorgegangen werden:
|
|
Statt alle Daten zu spiegeln, werden die Daten über
|
|
so viele Platten wie möglich gestriped. Die folgende
|
|
Konfiguration zeigt ein Volume
|
|
mit einem über vier Platten hinwegreichenden Plexus:</para>
|
|
|
|
<programlisting>
|
|
drive c device /dev/da5h
|
|
drive d device /dev/da6h
|
|
volume stripe
|
|
plex org striped 512k
|
|
sd length 128m drive a
|
|
sd length 128m drive b
|
|
sd length 128m drive c
|
|
sd length 128m drive d</programlisting>
|
|
|
|
<para>Wie zuvor ist es nicht nötig, die Platten zu
|
|
definieren, die Vinum schon bekannt sind. Nach dem Abarbeiten
|
|
dieser Definition sieht die Konfiguration wie folgt aus:</para>
|
|
|
|
<programlisting width="92">
|
|
Drives: 4 (4 configured)
|
|
Volumes: 3 (4 configured)
|
|
Plexes: 4 (8 configured)
|
|
Subdisks: 7 (16 configured)
|
|
|
|
D a State: up Device /dev/da3h Avail: 1421/2573 MB (55%)
|
|
D b State: up Device /dev/da4h Avail: 1933/2573 MB (75%)
|
|
D c State: up Device /dev/da5h Avail: 2445/2573 MB (95%)
|
|
D d State: up Device /dev/da6h Avail: 2445/2573 MB (95%)
|
|
|
|
V myvol State: up Plexes: 1 Size: 512 MB
|
|
V mirror State: up Plexes: 2 Size: 512 MB
|
|
V striped State: up Plexes: 1 Size: 512 MB
|
|
|
|
P myvol.p0 C State: up Subdisks: 1 Size: 512 MB
|
|
P mirror.p0 C State: up Subdisks: 1 Size: 512 MB
|
|
P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB
|
|
P striped.p1 State: up Subdisks: 1 Size: 512 MB
|
|
|
|
S myvol.p0.s0 State: up PO: 0 B Size: 512 MB
|
|
S mirror.p0.s0 State: up PO: 0 B Size: 512 MB
|
|
S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB
|
|
S striped.p0.s0 State: up PO: 0 B Size: 128 MB
|
|
S striped.p0.s1 State: up PO: 512 kB Size: 128 MB
|
|
S striped.p0.s2 State: up PO: 1024 kB Size: 128 MB
|
|
S striped.p0.s3 State: up PO: 1536 kB Size: 128 MB</programlisting>
|
|
|
|
<para>
|
|
<figure id="vinum-striped-vol">
|
|
<title>Ein Striped Vinum Volume</title>
|
|
<graphic fileref="vinum/vinum-striped-vol"/>
|
|
</figure>
|
|
</para>
|
|
|
|
<para>Dieses Volume wird in <xref linkend="vinum-striped-vol"/>
|
|
dargestellt. Die Schattierung der Stripes zeigt die Position
|
|
innerhalb des Plexus-Adressraumes an. Die hellsten Stripes
|
|
kommen zuerst, die dunkelsten zuletzt.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Ausfallsicherheit und Leistung</title>
|
|
|
|
<para><anchor id="vinum-resilience"/>Mit entsprechender Hardware
|
|
ist es möglich, Volumes zu bauen, welche gegenüber
|
|
Standard-&unix;-Partitionen beides, nämlich erhöhte
|
|
Ausfallsicherheit und erhöhte Leistung, aufweisen
|
|
können. Eine typische Konfigurationsdatei könnte
|
|
etwa so aussehen:</para>
|
|
|
|
<programlisting>
|
|
volume raid10
|
|
plex org striped 512k
|
|
sd length 102480k drive a
|
|
sd length 102480k drive b
|
|
sd length 102480k drive c
|
|
sd length 102480k drive d
|
|
sd length 102480k drive e
|
|
plex org striped 512k
|
|
sd length 102480k drive c
|
|
sd length 102480k drive d
|
|
sd length 102480k drive e
|
|
sd length 102480k drive a
|
|
sd length 102480k drive b</programlisting>
|
|
|
|
<para>Die Subdisks des zweiten Plexus sind gegenüber denen
|
|
des ersten Plexus um zwei Platten verschoben. Dadurch wird
|
|
sichergestellt, dass Schreibzugriffe nicht auf den gleichen
|
|
Subdisks auftreten, auch wenn eine Übertragung über
|
|
zwei Platten geht.</para>
|
|
|
|
<para><xref linkend="vinum-raid10-vol"/> veranschaulicht die
|
|
Struktur dieses Volumes.</para>
|
|
|
|
<para>
|
|
<figure id="vinum-raid10-vol">
|
|
<title>Ein gespiegeltes, Striped Vinum Volume</title>
|
|
<graphic fileref="vinum/vinum-raid10-vol"/>
|
|
</figure>
|
|
</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="vinum-object-naming">
|
|
<title>Objektbenennung</title>
|
|
|
|
<para>Wie oben beschrieben, weist Vinum den Plexus und
|
|
Subdisks Standardnamen zu, wenngleich diese überschrieben
|
|
werden können. Das Überschreiben dieser Standardnamen
|
|
wird allerdings nicht empfohlen. Erfahrungen mit dem VERITAS
|
|
Volume Manager (der eine willkürliche Benennung von
|
|
Objekten erlaubt) haben gezeigt, dass diese Flexibilität
|
|
keinen entscheidenden Vorteil bringt und zudem Verwirrung
|
|
stiften kann.</para>
|
|
|
|
<para>Namen dürfen zwar alle nichtleeren Zeichen enthalten,
|
|
es ist aber sinnvoll, nur Buchstaben, Ziffern und den
|
|
Unterstrich zu verwenden. Die Namen von Volumes, Plexus und
|
|
Subdisks können bis zu 64 Zeichen lang sein, die Namen
|
|
von Platten dürfen hingegen nur bis zu 32 Zeichen lang
|
|
sein.</para>
|
|
|
|
<para>Vinum-Objekten werden Gerätedateien in der <filename
|
|
class="directory">/dev/gvinum</filename>-Hierarchie zugewiesen. Die
|
|
weiter oben dargestellte Konfiguration würde Vinum dazu
|
|
veranlassen, die folgenden Gerätedateien zu erstellen:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Geräte-Einträge für jedes Volume.
|
|
Dieses sind die Hauptgeräte, die von Vinum benutzt
|
|
werden. Somit würde die Konfiguration von oben
|
|
folgende Geräte beinhalten:
|
|
<filename class="devicefile">/dev/gvinum/myvol</filename>,
|
|
<filename class="devicefile">/dev/gvinum/mirror</filename>,
|
|
<filename class="devicefile">/dev/gvinum/striped</filename>,
|
|
<filename class="devicefile">/dev/gvinum/raid5</filename> sowie
|
|
<filename class="devicefile">/dev/gvinum/raid10</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Alle Volumes bekommen direkte Einträge unter <filename
|
|
class="directory">/dev/gvinum/</filename>.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Die Verzeichnisse <filename
|
|
class="directory">/dev/gvinum/plex</filename> und <filename
|
|
class="directory">/dev/gvinum/sd</filename>, die Gerätedateien
|
|
für jeden Plexus sowie jede Subdisk enthalten.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Stellen Sie sich folgende Konfigurationsdatei vor:</para>
|
|
|
|
<programlisting>
|
|
drive drive1 device /dev/sd1h
|
|
drive drive2 device /dev/sd2h
|
|
drive drive3 device /dev/sd3h
|
|
drive drive4 device /dev/sd4h
|
|
volume s64 setupstate
|
|
plex org striped 64k
|
|
sd length 100m drive drive1
|
|
sd length 100m drive drive2
|
|
sd length 100m drive drive3
|
|
sd length 100m drive drive4</programlisting>
|
|
|
|
<para>Nach Abarbeitung dieser Datei erstellt &man.gvinum.8; die
|
|
folgende Struktur unter <filename
|
|
class="directory">/dev/gvinum</filename>:</para>
|
|
|
|
<programlisting>
|
|
drwxr-xr-x 2 root wheel 512 Apr 13 16:46 plex
|
|
crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 s64
|
|
drwxr-xr-x 2 root wheel 512 Apr 13 16:46 sd
|
|
|
|
/dev/vinum/plex:
|
|
total 0
|
|
crwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0
|
|
|
|
/dev/vinum/sd:
|
|
total 0
|
|
crwxr-xr-- 1 root wheel 91, 0x20000002 Apr 13 16:46 s64.p0.s0
|
|
crwxr-xr-- 1 root wheel 91, 0x20100002 Apr 13 16:46 s64.p0.s1
|
|
crwxr-xr-- 1 root wheel 91, 0x20200002 Apr 13 16:46 s64.p0.s2
|
|
crwxr-xr-- 1 root wheel 91, 0x20300002 Apr 13 16:46 s64.p0.s3</programlisting>
|
|
|
|
<para>Es wird empfohlen, für Plexus und Subdisks keine
|
|
eigenen Namen zu vergeben. Dies gilt aber nicht für
|
|
Vinum-Platten. Durch die Benennung von Vinum-Platten
|
|
wird es erst möglich, eine Platte an einen anderen Ort zu
|
|
verschieben und sie trotzdem noch automatisch erkennen zu lassen.
|
|
Plattennamen können bis zu 32 Zeichen lang sein.</para>
|
|
|
|
<sect2>
|
|
<title>Dateisysteme erstellen</title>
|
|
|
|
<para>Volumes erscheinen (mit einer Ausnahme) dem System nicht
|
|
anders als Platten. Anders als &unix;-Platten partitioniert
|
|
Vinum seine Volumes nicht, weshalb diese auch keine
|
|
Partitionstabellen haben. Dies wiederum hat Modifikationen an
|
|
einigen Platten-Tools, insbesondere &man.newfs.8;, nötig
|
|
gemacht, welche bis dahin den letzten Buchstaben eines
|
|
Vinum-Volume-Namen als Partitionsbezeichner identifiziert haben.
|
|
Zum Beispiel könnte eine Platte einen Namen wie
|
|
<filename class="devicefile">/dev/ad0a</filename> oder
|
|
<filename class="devicefile">/dev/da2h</filename> haben. Diese Namen
|
|
bedeuten, dass es sich um die erste Partition
|
|
(<devicename>a</devicename>) der ersten (0) IDE-Platte
|
|
(<devicename>ad</devicename>) und respektive die achte
|
|
Partition (<devicename>h</devicename>) der dritten (2)
|
|
SCSI-Platte (<devicename>da</devicename>) handelt. Im Vergleich
|
|
dazu könnte ein Vinum-Volume beispielsweise <filename
|
|
class="devicefile">/dev/gvinum/concat</filename> heißen, ein Name,
|
|
der in keiner Beziehung mit einem Partitionsnamen steht.</para>
|
|
|
|
<para>Um nun ein Dateisystem auf diesem Volume anzulegen, benutzen
|
|
Sie &man.newfs.8;:</para>
|
|
|
|
<screen>&prompt.root; <userinput>newfs /dev/gvinum/concat</userinput></screen>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="vinum-config">
|
|
<title>Vinum konfigurieren</title>
|
|
|
|
<para>Der <filename>GENERIC</filename>-Kernel enthät kein
|
|
Vinum. Es ist zwar möglich, einen speziellen Kernel zu
|
|
bauen, der Vinum beinhaltet, empfohlen wird aber, Vinum als
|
|
ein Kernelmodul (über <acronym>kld</acronym>) zu laden.
|
|
Dazu müssen Sie nicht einmal &man.kldload.8; benutzen,
|
|
da beim Start von &man.gvinum.8; automatisch überprüft
|
|
wird, ob das Modul bereits geladen wurde. Falls das Modul noch
|
|
nicht geladen wurde, wird es daraufhin geladen.</para>
|
|
|
|
<sect2>
|
|
<title>Inbetriebnahme</title>
|
|
|
|
<para>Vinum speichert seine Konfigurationsinformationen auf den
|
|
Platten-Slices im Wesentlichen genauso ab wie in den
|
|
Konfigurationsdateien. Beim Lesen der Konfigurationsdatenbank
|
|
erkennt Vinum eine Anzahl von Schlüsselwörtern, die
|
|
in den Konfigurationsdateien nicht erlaubt sind. Zum Beispiel
|
|
könnte eine Platten-Konfiguration den folgenden Text
|
|
enthalten:</para>
|
|
|
|
<programlisting width="119">volume myvol state up
|
|
volume bigraid state down
|
|
plex name myvol.p0 state up org concat vol myvol
|
|
plex name myvol.p1 state up org concat vol myvol
|
|
plex name myvol.p2 state init org striped 512b vol myvol
|
|
plex name bigraid.p0 state initializing org raid5 512b vol bigraid
|
|
sd name myvol.p0.s0 drive a plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 0b
|
|
sd name myvol.p0.s1 drive b plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 1048576b
|
|
sd name myvol.p1.s0 drive c plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 0b
|
|
sd name myvol.p1.s1 drive d plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 1048576b
|
|
sd name myvol.p2.s0 drive a plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 0b
|
|
sd name myvol.p2.s1 drive b plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 524288b
|
|
sd name myvol.p2.s2 drive c plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1048576b
|
|
sd name myvol.p2.s3 drive d plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1572864b
|
|
sd name bigraid.p0.s0 drive a plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 0b
|
|
sd name bigraid.p0.s1 drive b plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 4194304b
|
|
sd name bigraid.p0.s2 drive c plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 8388608b
|
|
sd name bigraid.p0.s3 drive d plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 12582912b
|
|
sd name bigraid.p0.s4 drive e plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 16777216b</programlisting>
|
|
|
|
<para>Die offensichtlichen Unterschiede sind hier die Anwesenheit
|
|
von Informationen über explizite Speicherorte und
|
|
Benennungen (beides ist zwar erlaubt, aber es wird dem Benutzer
|
|
davon abgeraten, es zu benutzen) und Informationen über die
|
|
Zustände (welche für den Benutzer nicht zur
|
|
Verfügung stehen). Vinum speichert keine Informationen
|
|
über Platten in den Konfigurationsinformationen, es findet
|
|
die Platten durch Scannen nach Vinum-Markierungen auf den
|
|
eingerichteten Laufwerken. Dies ermöglicht es,
|
|
Vinum-Platten auch dann noch korrekt zu identifizieren, wenn
|
|
sie schon andere &unix;-Platten-IDs zugewiesen bekommen
|
|
haben.</para>
|
|
|
|
<sect3 id="vinum-rc-startup">
|
|
<title>Automatische Inbetriebnahme</title>
|
|
|
|
<note>
|
|
<para><emphasis>Gvinum</emphasis>
|
|
unterstützt eine automatische Inbetriebnahme immer,
|
|
wenn das Kernelmodul über &man.loader.conf.5; geladen ist.
|
|
Um das <emphasis>Gvinum</emphasis> Modul beim Hochfahren des
|
|
Systems zu laden, fügen Sie die Zeile
|
|
<literal>geom_vinum_load="YES"</literal> in
|
|
<filename>/boot/loader.conf</filename> ein.</para>
|
|
</note>
|
|
|
|
<para>Beim starten von Vinum durch den Befehl <command>vinum
|
|
start</command> liest Vinum die Konfigurationsdatenbank von
|
|
einer der Vinum-Platten. Unter normalen Umständen
|
|
enthält jede Platte eine identische Kopie der
|
|
Konfigurationsdatenbank, so dass es keine Rolle spielt, von
|
|
welcher der Platten diese eingelesen wird. Nach einem
|
|
Plattencrash muss Vinum allerdings zunächst feststellen,
|
|
welche der Platten zuletzt aktualisiert wurde und dann die
|
|
Konfiguration von dieser Platte lesen. Danach werden (falls
|
|
nötig) die Konfigurationen der "alten" Platten
|
|
aktualisiert.</para>
|
|
</sect3>
|
|
</sect2>
|
|
</sect1>
|
|
<!-- 2006-01-04__16:15 -->
|
|
<sect1 id="vinum-root">
|
|
<title>Vinum für das Root-Dateisystem benutzen</title>
|
|
|
|
<para>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:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Das Root-Dateisystem in einer sehr frühen Phase
|
|
des Bootvorgangs verfügbar sein muss, und damit auch
|
|
die Vinum-Infrastruktur.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>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.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>Im folgenden Abschnitt wird der Begriff
|
|
<quote>Root-Volume</quote> benutzt, um das Vinum-Volume zu
|
|
beschreiben, welches das Root-Dateisystem enthält. Es ist
|
|
eine gute Idee, für dieses Volume den Namen
|
|
<literal>"root"</literal> zu benutzen, aber es ist in keiner
|
|
Weise technisch nötig (Das folgende Beispiel geht allerdings
|
|
davon aus, dass dies der Fall ist.).</para>
|
|
|
|
<sect2>
|
|
<title>Vinum für das Root-Dateisystem rechtzeitig
|
|
starten</title>
|
|
|
|
<para>Damit dies gelingt, müssen Sie folgende Aufgaben
|
|
erledigen:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Vinum muss zum Zeitpunkt des Bootvorganges im
|
|
Kernel zur Verfügung stehen. Deswegen ist die
|
|
Methode zum Start von Vinum, die in
|
|
<xref linkend="vinum-rc-startup"/> beschrieben wird,
|
|
für diese Aufgabe nicht geeignet. Also muss
|
|
auch der <literal>start_vinum</literal>-Parameter
|
|
eigentlich <emphasis>nicht</emphasis> 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
|
|
<filename>/boot/loader</filename>
|
|
(<xref linkend="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</para>
|
|
|
|
<programlisting>geom_vinum_load="YES"</programlisting>
|
|
|
|
<para>in die Datei <filename>/boot/loader.conf</filename>
|
|
eingetragen wird.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Für <emphasis>Gvinum</emphasis> ist das oben
|
|
beschriebene Prozedere alles, was Sie tun müssen,
|
|
da der gesamte Startvorgang automatisch erledigt wird,
|
|
sobald das Kernelmodul geladen wurde.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Ein Vinum-basiertes Root-Volume dem Bootstrap
|
|
verfügbar machen</title>
|
|
|
|
<para>Da der aktuelle &os;-Bootstrap nur 7,5 KB Code
|
|
enthält und schon ohne Vinum die Aufgabe hat,
|
|
bestimmte Dateien (wie <filename>/boot/loader</filename>)
|
|
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-<literal>"a"</literal>-Partition mit
|
|
einem Root-Dateisystem vorzugaukeln.</para>
|
|
|
|
<para>Damit dies überhaupt möglich wird,
|
|
müssen die folgenden Bedingungen für das
|
|
Root-Dateisystem erfüllt sein:</para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>Das Root-Volume darf weder gestriped noch
|
|
RAID-5 sein.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Das Root-Volume darf nicht mehr als eine konkatenierte
|
|
Subdisk pro Plexus enthalten.</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<para>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 <literal>"a"</literal> brauchen,
|
|
damit das entsprechende Gerät bootbar wird. Es ist nicht
|
|
unbedingt notwendig, dass sich jede dieser gefälschten
|
|
<literal>"a"</literal>-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.</para>
|
|
|
|
<para>Damit diese <literal>"a"</literal>-Partitionen eingerichtet
|
|
werden können, muss für alle Geräte, die Teil des
|
|
Root-Dateisystems sind, folgendes getan werden:</para>
|
|
|
|
<procedure>
|
|
<step>
|
|
<para>Der Ort (Verschiebung vom Beginn des Gerätes) und
|
|
die Größe der Subdisk, die Teil des Root-Volumes
|
|
ist, muss untersucht werden:</para>
|
|
|
|
<screen>&prompt.root; <userinput>gvinum l -rv root</userinput></screen>
|
|
|
|
<para>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 <command>bsdlabel</command>-Kommando
|
|
verwendet.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Führen Sie den Befehl</para>
|
|
|
|
<screen>&prompt.root; <userinput>bsdlabel -e <replaceable>devname</replaceable></userinput></screen>
|
|
|
|
<para>für jedes Gerät, dass am Root-Volume beteiligt
|
|
ist, aus. <replaceable>devname</replaceable> muss entweder
|
|
der Name der Platte (wie <devicename>da0</devicename>), im
|
|
Falle einer Platte ohne Slice-Tabelle oder der Name des
|
|
Slices (wie <devicename>ad0s1</devicename>) sein.</para>
|
|
|
|
<para>Wenn es schon eine <literal>"a"</literal>-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 <quote>Fixit</quote>-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.</para>
|
|
|
|
<para>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 <literal>"offset"</literal>-Wert für
|
|
die neue <literal>"a"</literal>-Partition. Der
|
|
<literal>"size"</literal>-Wert für diese Partition
|
|
kann entsprechend der Berechnung ermittelt werden.
|
|
<literal>"fstype"</literal> sollte <literal>4.2BSD</literal>
|
|
sein. Die <literal>"fsize"</literal>-,
|
|
<literal>"bsize"</literal>-, und
|
|
<literal>"cpg"</literal>- Werte sollten entsprechend dem
|
|
eigentlichen Dateisystem gewählt werden, obwohl sie in
|
|
diesem Kontext ziemlich unwichtig sind.</para>
|
|
|
|
<para>Auf diese Art und Weise wird eine neue Partition
|
|
<literal>"a"</literal> etabliert, die die Vinum-Partition
|
|
auf diesem Gerät überschneidet. Beachte Sie, dass
|
|
das <command>bsdlabel</command>-Kommando diese
|
|
Überschneidung nur erlaubt, wenn die Partition richtig
|
|
mit dem <literal>"vinum"</literal>-fstype markiert ist.</para>
|
|
</step>
|
|
|
|
<step>
|
|
<para>Das ist alles. Auf jedem Gerät befindet sich nun
|
|
eine gefälschte <literal>"a"</literal>-Partition, die
|
|
eine Kopie des Root-Volumes enthält. Es wird dringend
|
|
empfohlen, das Resultat dieser Konfiguration zu
|
|
überprüfen:</para>
|
|
|
|
<screen>&prompt.root; <userinput>fsck -n /dev/<replaceable>devname</replaceable>a</userinput></screen>
|
|
</step>
|
|
</procedure>
|
|
|
|
<para>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 <filename>/etc/fstab</filename> und
|
|
<filename>/boot/loader.conf</filename> überprüft
|
|
werden.</para>
|
|
|
|
<para>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:</para>
|
|
|
|
<screen>Mounting root from ufs:/dev/gvinum/root</screen>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Beispiel eines Vinum-basierten Root-Setups</title>
|
|
|
|
<para>Nachdem das Vinum-Root-Volume eingerichtet wurde,
|
|
könnte die Ausgabe von <command>gvinum l -rv root</command>
|
|
bespielsweise so aussehen:</para>
|
|
|
|
<screen>
|
|
...
|
|
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)
|
|
</screen>
|
|
|
|
<para>Wichtig ist hier insbesondere ist der Wert
|
|
<literal>135680</literal> für die Verschiebung (relativ zur
|
|
Partition <filename
|
|
class="devicefile">/dev/da0h</filename>). Das entspricht
|
|
beim Einsatz von <command>bsdlabel</command> 265
|
|
512-Byte-Plattenblöcken. Dieses Root-Volume ist ebenso
|
|
245760 512-Byte-Blöcke groß.
|
|
<filename class="devicefile">/dev/da1h</filename> enthält die
|
|
zweite Kopie dieses Root-Volumes und ist symmetrisch aufgebaut.</para>
|
|
|
|
<para>Das Bsdlabel für diese Geräte könnte
|
|
so aussehen:</para>
|
|
|
|
<screen>
|
|
...
|
|
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*)
|
|
</screen>
|
|
|
|
<para>Wie man leicht feststellen kann, entspricht der Parameter
|
|
<literal>"size"</literal> der gefälschten
|
|
<literal>"a"</literal>-Partition dem ausgewiesenen Wert von
|
|
oben, während der Parameter
|
|
<literal>"offset"</literal> gleich der Summe der Verschiebung
|
|
innerhalb der Vinum-Partition <literal>"h"</literal> und der
|
|
Verschiebung innerhalb des Geräts (oder Slice) ist. Dies
|
|
ist ein typischer Aufbau, der nötig ist, um die in
|
|
<xref linkend="vinum-root-panic"/> beschriebenen Probleme zu
|
|
vermeiden. Die gesamte Partition <literal>"a"</literal> befindet
|
|
sich in <literal>"h"</literal>, die alle Vinum-Daten für
|
|
dieses Gerät enthält.</para>
|
|
|
|
<para>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.</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Fehlerbehebung</title>
|
|
|
|
<para>Der folgende Abschnitt beschreibt einige bekannte
|
|
Probleme und Fallstricke bei der Vinum-Konfiguration sowie
|
|
deren Behebung.</para>
|
|
|
|
<sect3>
|
|
<title>Der System-Bootstrap lädt zwar, das System startet
|
|
aber nicht.</title>
|
|
|
|
<para>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
|
|
<keycap>Leertaste</keycap> unterbrechen. Die
|
|
<foreignphrase>loader</foreignphrase>-Variablen (wie
|
|
<literal>vinum.autostart</literal>) können mittels des
|
|
<command>show</command>-Kommandos untersucht, und mit
|
|
<command>set</command> oder <command>unset</command>
|
|
geändert werden.</para>
|
|
|
|
<para>Wenn das einzige Problem das Fehlen des
|
|
Vinum-Kernelmoduls in der Liste der automatisch zu ladenden
|
|
Module ist, hilft ein einfaches
|
|
<command>load geom_vinum</command>.</para>
|
|
|
|
<para>Danach können Sie den Bootvorgang mit
|
|
<command>boot -as</command> fortsetzen. Die Optionen
|
|
<option>-as</option> fordern den Kernel auf, nach dem zu
|
|
mountenden Root-Dateisystem zu fragen (<option>-a</option>),
|
|
und den Bootvorgang im Single-User-Modus
|
|
(<option>-s</option>) 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.</para>
|
|
|
|
<para>Beim Prompt, das nach einem Root-Dateisystem fragt,
|
|
kann jedes Gerät angegeben werden, dass ein
|
|
gültiges Root-Dateisystem hat. Wenn
|
|
<filename>/etc/fstab</filename> richtig konfiguriert
|
|
wurde, sollte die Vorgabe etwas wie
|
|
<literal>ufs:/dev/gvinum/root</literal> sein. Eine typische
|
|
Alternative würde etwas wie
|
|
<literal>ufs:da0d</literal> sein, welches eine
|
|
hypothetische Partition sein könnte, die ein
|
|
Pre-Vinum-Root-Dateisystem enthält. Vorsicht sollte
|
|
walten, wenn eine der <foreignphrase>alias</foreignphrase>
|
|
<literal>"a"</literal>-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.</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Nur der primäre Bootstrap lädt</title>
|
|
|
|
<para>Wenn das Laden von <filename>/boot/loader</filename>
|
|
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
|
|
<keycap>Leertaste</keycap> zu unterbrechen. Dies wird
|
|
den Bootstrap in der zweiten Phase stoppen (siehe dazu auch
|
|
<xref linkend="boot-boot1"/>). Hier kann nun der Versuch
|
|
unternommen werden, von einer anderen Partition zu booten,
|
|
wie beispielsweise dem vorhergehenden Root-Dateisystem,
|
|
das von <literal>"a"</literal> verschoben wurde.</para>
|
|
</sect3>
|
|
|
|
<sect3 id="vinum-root-panic">
|
|
<title>Nichts bootet, der Bootstrap hängt sich auf</title>
|
|
|
|
<para>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
|
|
<foreignphrase>bsdlabel</foreignphrase> 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.</para>
|
|
|
|
<para>Analog wird eine anschließende
|
|
Reinstallation eines Bootstrap (zum Beispiel durch Booten
|
|
eines <quote>Fixit</quote>-Mediums) mit
|
|
<command>bsdlabel -B</command>, wie in
|
|
<xref linkend="boot-boot1"/> 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.</para>
|
|
</sect3>
|
|
</sect2>
|
|
</sect1>
|
|
</chapter>
|