diff --git a/de_DE.ISO8859-1/books/handbook/vinum/chapter.sgml b/de_DE.ISO8859-1/books/handbook/vinum/chapter.sgml
index 664b340ddf..fe66c19dc3 100644
--- a/de_DE.ISO8859-1/books/handbook/vinum/chapter.sgml
+++ b/de_DE.ISO8859-1/books/handbook/vinum/chapter.sgml
@@ -1,1440 +1,1440 @@
<?xml version="1.0" encoding="ISO8859-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
+<!--
+ 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><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>
+
+ <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>
diff --git a/en_US.ISO8859-1/htdocs/layout/Makefile b/en_US.ISO8859-1/htdocs/layout/Makefile
index 64c5e8d595..e468f29618 100644
--- a/en_US.ISO8859-1/htdocs/layout/Makefile
+++ b/en_US.ISO8859-1/htdocs/layout/Makefile
@@ -1,4 +1,4 @@
-# $FreeBSD$
+# $FreeBSD$
.if exists(../Makefile.conf)
.include "../Makefile.conf"
diff --git a/ja_JP.eucJP/htdocs/ports/comments.ja b/ja_JP.eucJP/htdocs/ports/comments.ja
index 292c1c9e64..3d2927f21d 100644
--- a/ja_JP.eucJP/htdocs/ports/comments.ja
+++ b/ja_JP.eucJP/htdocs/ports/comments.ja
@@ -610,7 +610,7 @@ devel/SpecTcl|Sun
devel/a2dev|Apple II 6502 �ѤΥ�����֥顦����������ȥ��֥������ȥե�����ӥ塼��
###|devel/adabroker|A full Ada ORB to develop CORBA application
devel/amulet|�ե�� C++ GUI �饤�֥��
-###|devel/arm-aout-binutils|FSF Binutils for embedded ARM cross-development
+###|devel/arm-aout-binutils|FSF Binutils for embedded ARM cross-development
###|devel/arm-aout-gcc295|FSF Gcc 2.95.2 for embedded ARM cross-development
###|devel/arm-elf-binutils|GNU binutils for vanilla ARM cross-development
###|devel/arm-elf-gcc295|GNU cross compiler suite for vanilla ARM targets.