diff options
| author | Johann Kois <jkois@FreeBSD.org> | 2007-01-06 10:39:59 +0000 |
|---|---|---|
| committer | Johann Kois <jkois@FreeBSD.org> | 2007-01-06 10:39:59 +0000 |
| commit | 906c1f21be9cd64e644f25a7da05afba1248261d (patch) | |
| tree | 6998fdbc124c2a1eec29b3813f81ab6fffc3f431 /de_DE.ISO8859-1 | |
| parent | 93bddf561b8a2f0926cddbc72d08b906826bcfe7 (diff) | |
| download | doc-906c1f21be9cd64e644f25a7da05afba1248261d.tar.gz doc-906c1f21be9cd64e644f25a7da05afba1248261d.zip | |
MFbed: Update the German documentation set.
doc/de_DE.ISO8859-1/books/handbook/book.sgml 1.168 -> 1.169
doc/de_DE.ISO8859-1/books/handbook/disks/chapter.sgml 1.268 -> 1.269
doc/de_DE.ISO8859-1/books/handbook/install/chapter.sgml 1.339 -> 1.344
doc/de_DE.ISO8859-1/books/handbook/mirrors/chapter.sgml 1.421 -> 1.422
doc/de_DE.ISO8859-1/books/handbook/security/chapter.sgml 1.308 -> 1.311
doc/de_DE.ISO8859-1/books/handbook/vinum/chapter.sgml new translation [X]
doc/de_DE.ISO8859-1/share/sgml/glossary/freebsd-glossary.sgml 1.24 -> 1.25
Obtained from: The FreeBSD German Documentation Project.
[X] Contributed by Kay Abendroth (kay.abendroth at raxion dot net)
Notes
Notes:
svn path=/head/; revision=29331
Diffstat (limited to 'de_DE.ISO8859-1')
| -rw-r--r-- | de_DE.ISO8859-1/books/handbook/book.sgml | 5 | ||||
| -rw-r--r-- | de_DE.ISO8859-1/books/handbook/disks/chapter.sgml | 6 | ||||
| -rw-r--r-- | de_DE.ISO8859-1/books/handbook/install/chapter.sgml | 356 | ||||
| -rw-r--r-- | de_DE.ISO8859-1/books/handbook/mirrors/chapter.sgml | 6 | ||||
| -rw-r--r-- | de_DE.ISO8859-1/books/handbook/security/chapter.sgml | 4 | ||||
| -rw-r--r-- | de_DE.ISO8859-1/books/handbook/vinum/chapter.sgml | 1650 | ||||
| -rw-r--r-- | de_DE.ISO8859-1/share/sgml/glossary/freebsd-glossary.sgml | 8 |
7 files changed, 1756 insertions, 279 deletions
diff --git a/de_DE.ISO8859-1/books/handbook/book.sgml b/de_DE.ISO8859-1/books/handbook/book.sgml index 3193a4c63b..c40a0f230b 100644 --- a/de_DE.ISO8859-1/books/handbook/book.sgml +++ b/de_DE.ISO8859-1/books/handbook/book.sgml @@ -3,8 +3,8 @@ The FreeBSD German Documentation Project $FreeBSD$ - $FreeBSDde: de-docproj/books/handbook/book.sgml,v 1.78 2006/10/21 14:07:02 jkois Exp $ - basiert auf: 1.168 + $FreeBSDde: de-docproj/books/handbook/book.sgml,v 1.79 2007/01/05 19:43:44 jkois Exp $ + basiert auf: 1.169 --> <!DOCTYPE BOOK PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [ @@ -82,6 +82,7 @@ <year>2004</year> <year>2005</year> <year>2006</year> + <year>2007</year> <holder>The FreeBSD German Documentation Project</holder> </copyright> diff --git a/de_DE.ISO8859-1/books/handbook/disks/chapter.sgml b/de_DE.ISO8859-1/books/handbook/disks/chapter.sgml index 5fd98748d5..89b8a452aa 100644 --- a/de_DE.ISO8859-1/books/handbook/disks/chapter.sgml +++ b/de_DE.ISO8859-1/books/handbook/disks/chapter.sgml @@ -3,8 +3,8 @@ The FreeBSD German Documentation Project $FreeBSD$ - $FreeBSDde: de-docproj/books/handbook/disks/chapter.sgml,v 1.148 2006/12/07 20:34:46 jkois Exp $ - basiert auf: 1.268 + $FreeBSDde: de-docproj/books/handbook/disks/chapter.sgml,v 1.149 2007/01/04 16:16:05 jkois Exp $ + basiert auf: 1.269 --> <chapter id="disks"> @@ -942,7 +942,7 @@ da0: 126MB (258048 512 byte sectors: 64H 32S/T 126C)</screen> in die Konfigurationsdatei <filename>/etc/sysctl.conf</filename> ein:</para> - <programlisting>vfs.usermount="1"</programlisting> + <programlisting>vfs.usermount=1</programlisting> <para>Damit diese Einstellung wirksam wird, müssen Sie Ihr System neu starten. Alternativ können Sie diese Variable diff --git a/de_DE.ISO8859-1/books/handbook/install/chapter.sgml b/de_DE.ISO8859-1/books/handbook/install/chapter.sgml index b3d684b065..8a3aa249d1 100644 --- a/de_DE.ISO8859-1/books/handbook/install/chapter.sgml +++ b/de_DE.ISO8859-1/books/handbook/install/chapter.sgml @@ -2,8 +2,8 @@ The FreeBSD Documentation Project $FreeBSD$ - $FreeBSDde: de-docproj/books/handbook/install/chapter.sgml,v 1.42 2006/12/12 19:25:38 jkois Exp $ - basiert auf: 1.339 + $FreeBSDde: de-docproj/books/handbook/install/chapter.sgml,v 1.46 2007/01/06 09:37:56 jkois Exp $ + basiert auf: 1.344 --> <chapter id="install"> @@ -25,7 +25,6 @@ Bildschirmabzüge von </contrib> </author> </authorgroup> - <!-- January 2000 --> <authorgroup> <author> @@ -97,6 +96,116 @@ </note> </sect1> + <sect1 id="install-hardware"> + <title>Hardware-Anforderungen</title> + + <sect2 id="install-hardware-minimal"> + <title>Minimalkonfiguration</title> + + <para>Die zur Installation von &os; erforderliche + Minimalkonfiguration hängt von der zu installierenden + &os;-Version sowie von der Hardware-Architektur ab.</para> + + <para>Informationen zur jeweiligen Minimalkonfiguration finden + Sie in Installation Notes auf der Unterseite <ulink + url="&url.base;/de/releases/index.html">Release + Information</ulink> der &os;-Internetseiten. Die folgenden + Abschnitte fassen diese Informationen zusammen. Je nachdem, + wie Sie &os; installieren, benötigen Sie eventuell auch + ein Diskettenlaufwerk, ein unterstütztes CD-ROM-Laufwerk, + oder auch eine Netzwerkkarte. <xref + linkend="install-floppies"> des Handbuchs enthält + weitere Informationen zu den verschiedenen + Installationsarten.</para> + + <sect3> + <title>Die i386- und pc98-Architektur</title> + + <para>Sowohl &os;/i386 als auch &os;/pc98 benötigen + jeweils mindestens einen 486-Prozessor sowie mindestens + 24 MB RAM. Außerdem benötigen Sie für + eine Minimalinstallation mindestens 150 MB freien + Platz auf Ihrer Festplatte.</para> + + <note> + <para>In den meisten derartigen Konfigurationen ist es + besser, für mehr RAM und mehr Plattenplatz zu sorgen, + statt einen schnelleren Prozessor einzubauen.</para> + </note> + </sect3> + + <sect3> + <title>Die Alpha-Architektur</title> + + <para>Um &os;/alpha zu installieren, benötigen Sie + eine unterstützte Plattorm (lesen Sie dazu auch + <xref linkend="install-hardware-supported"> des + Handbuchs) sowie eine + seperate Festplatte für die &os;-Installation. + Es ist nicht derzeit möglich, die Platte mit einem + weiteren Betriebssystem zu teilen. Diese seperate Platte + muss an einen SCSI-Controller angeschlossen sein, der von + der SRM-Firmware unterstützt wird. Alternativ + können Sie auch eine IDE-Platte verwenden, wenn Ihr + SRM das Starten von IDE-Platten unterstützt.</para> + + <para>Für die &os;-Installation benötigen Sie die + SRM-Konsolen-Firmware für Ihre Plattform. Manchmal + ist es möglich, zwischen der AlphaBIOS-Firmware + (auch ARC genannt) und SRM zu wechseln. Ist dies bei + Ihnen nicht möglich, müssen Sie sich die neue + Firmware von der Internetseite Ihres Herstellers + herunterladen.</para> + </sect3> + + <sect3> + <title>Die amd64-Architektur</title> + + <para>&os;/amd64 benötigt für den Betrieb + mindestens einen AMD Athlon 64-, + AMD Athlon 64-FX-, oder einen + AMD Opteron-Prozessor.</para> + + <para>Wenn Sie einen auf dem Chipsatz nVidia nForce3 Pro-150 + basierenden Rechner haben, <emphasis>müssen</emphasis> + Sie im BIOS das IO-APIC deaktivieren. Erlaubt ihr BIOS + dies nicht, müssen Sie stattdessen ACPI deaktivieren. + Der Grund dafür sind Fehler im Pro-150-Chipsatz, die + bis jetzt nicht behoben werden konnten.</para> + </sect3> + + <sect3> + <title>Die &sparc64;-Architektur</title> + + <para>Um &os;/&sparc64; zu installieren, benötigen Sie + eine unterstützte Plattform (lesen Sie dazu auch + <xref linkend="install-hardware-supported"> des + Handbuchs).</para> + + <para>Sie benötigen außerdem eine seperate + Festplatte, wenn Sie &os;/&sparc64; installieren wollen, + da es derzeit leider noch nicht möglich ist, die + Platte mit einem weiteren Betriebssystem zu teilen.</para> + </sect3> + </sect2> + + <sect2 id="install-hardware-supported"> + <title>Unterstützte Hardware</title> + + <para>Die Hardware-Notes, die mit jedem &os;-Release + ausgeliefert werden, enthalten eine Liste lauffähiger + Hardware. Die Hardware-Notes befinden sich üblicherweise + in der Datei <filename>HARDWARE.TXT</filename> im + Wurzelverzeichnis der Distribution (CD-ROM oder FTP). + Sie können die Hardware-Notes außerdem im + Dokumentationsmenü von + <application>sysinstall</application> oder auf der Webseite + <ulink + url="&url.base;/de/releases/index.html">Release Information</ulink> + lesen.</para> + </sect2> + </sect1> + <sect1 id="install-pre"> <title>Vor der Installation</title> @@ -215,6 +324,11 @@ </tbody> </tgroup> </table> + + <para>Nachdem Sie wissen, über welche Hardware Ihr Rechner + verfügt, müssen Sie diese Informationen mit den + Hardwareanforderungen der zu installierenden &os;-Version + abgleichen.</para> </sect2> <sect2> @@ -2944,193 +3058,6 @@ Press [Enter] now to invoke an editor on /etc/exports </sect3> </sect2> - <sect2 id="securityprofile"> - <title>Sicherheitsprofil</title> - - <para>Ein Sicherheitsprofil - (<foreignphrase>security profile</foreignphrase>) ist eine - Sammlung von Einstellungen, die versucht, ein vorgegebenes - Verhältnis von Sicherheit und Bedienbarkeit einzustellen. - Dazu werden bestimmte Programme und Optionen aktiviert oder - deaktiviert. Je schärfer das Sicherheitsprofil ist, - desto weniger Programme werden in der Voreinstellung - aktiviert. Dies ist einer der Sicherheitsgrundsätze: - Lassen Sie nur die Programme laufen, die Sie auch - wirklich benötigen.</para> - - <para>Beachten Sie, dass ein Sicherheitsprofil nur eine - Vorgabe ist. Nachdem Sie &os; installiert haben, können - Sie alle Programme in der Datei <filename>/etc/rc.conf</filename> - aktivieren oder deaktivieren. Weiteres erfahren Sie in - der Hilfeseite &man.rc.conf.5;.</para> - - <para>Die Sicherheitsprofile sind in der nachstehenden Tabelle - zusammengefasst. In den Spalten stehen die möglichen - Sicherheitsprofile, in den Reihen sind die Programme oder - Funktionen aufgeführt, die ein Profil aktiviert oder - deaktiviert.</para> - - <table> - <title>Mögliche Sicherheitsprofile</title> - - <tgroup cols=3> - <thead> - <row> - <entry></entry> - - <entry>Extreme</entry> - - <entry>Moderate</entry> - </row> - </thead> - - <tbody> - - <row> - <entry>&man.sendmail.8;</entry> - - <entry>nein</entry> - - <entry>ja</entry> - </row> - - <row> - <entry>&man.sshd.8;</entry> - - <entry>nein</entry> - - <entry>ja</entry> - </row> - - <row> - <entry>&man.portmap.8;</entry> - - <entry>nein</entry> - - <entry>unter Umständen - <footnote> - <para>Der Portmapper ist aktiviert, wenn der - Rechner vorher als <acronym>NFS</acronym>-Client - oder <acronym>NFS</acronym>-Server konfiguriert - wurde.</para> - </footnote> - </entry> - </row> - - <row> - <entry>NFS-Server</entry> - - <entry>nein</entry> - - <entry>ja</entry> - </row> - - <row> - <entry>&man.securelevel.8;</entry> - - <entry>ja - <footnote> - <para>Beachten Sie die Auswirkungen, wenn Sie - ein Sicherheitsprofil auswählen, dass - den Securelevel auf <quote>Extreme</quote> - oder <quote>High</quote> setzt. Damit Sie - später nicht in erhebliche Schwierigkeiten - geraten, lesen Sie bitte die Hilfeseite - &man.init.8; und achten Sie besonders auf die - Auswirkungen des Securelevels.</para> - </footnote> - </entry> - - <entry>nein</entry> - </row> - </tbody> - </tgroup> - </table> - - <screen> User Confirmation Requested - Do you want to select a default security profile for this host (select - No for "medium" security)? - - [ Yes ] No</screen> - - <para>Wenn Sie &gui.no; und - <keycap>Enter</keycap> drücken, wird das - Sicherheitsprofile auf <literal>medium</literal> gesetzt.</para> - - <para>Ein anderes Sicherheitsprofil stellen Sie ein, indem - Sie &gui.yes; auswählen und - <keycap>Enter</keycap> drücken.</para> - - <figure id="security-profile"> - <title>Ein Sicherheitsprofil auswählen</title> - - <mediaobject> - <imageobject> - <imagedata fileref="install/security" format="PNG"> - </imageobject> - </mediaobject> - </figure> - - <para>Mit <keycap>F1</keycap> können Sie einen - Hilfebildschirm aufrufen. Um den Hilfebildschirm - zu verlassen, drücken Sie die Taste - <keycap>Enter</keycap>.</para> - - <para>Wählen Sie mit den Pfeiltasten - <guimenuitem>Medium</guimenuitem> aus, wenn Sie nicht absolut - sicher sind, dass Sie ein anderes Sicherheitsprofil - benötigen. Schließen Sie die Auswahl mit - &gui.ok; und der Taste <keycap>Enter</keycap> ab.</para> - - <para>Es erscheint eine Bestätigung, die vom - ausgewählten Sicherheitsprofil abhängt.</para> - - <screen> Message - -Moderate security settings have been selected. - -Sendmail and SSHd have been enabled, securelevels are -disabled, and NFS server setting have been left intact. -PLEASE NOTE that this still does not save you from having -to properly secure your system in other ways or exercise -due diligence in your administration, this simply picks -a standard set of out-of-box defaults to start with. - -To change any of these settings later, edit /etc/rc.conf - - [OK]</screen> - - <screen> Message - -Extreme security settings have been selected. - -Sendmail, SSHd, and NFS services have been disabled, and -securelevels have been enabled. -PLEASE NOTE that this still does not save you from having -to properly secure your system in other ways or exercise -due diligence in your administration, this simply picks -a more secure set of out-of-box defaults to start with. - -To change any of these settings later, edit /etc/rc.conf - - [OK]</screen> - - <para>Drücken Sie <keycap>Enter</keycap>, um mit - den Nacharbeiten fortzufahren.</para> - - <warning> - <para>Ein Sicherheitsprofil ist kein Allheilmittel! - Auch wenn Sie ein scharfes Sicherheitsprofil verwenden, - müssen Sie über aktuelle Sicherheitsprobleme - informiert sein. Lesen Sie eine angemessene Mailingliste - (<xref linkend="eresources-mail">), - benutzen Sie gute Passwörter und Passphrases - und halten Sie sich an bekannte Verfahren. - Ein Sicherheitsprofil stellt nur das gewünschte - Verhältnis von Sicherheit und Bedienbarkeit ein.</para> - </warning> - </sect2> - <sect2 id="console"> <title>Die Systemkonsole einrichten</title> @@ -4953,34 +4880,6 @@ Please press any key to reboot.</screen> </sect2> </sect1> - <sect1 id="install-supported-hardware"> - <title>Unterstützte Hardware</title> - - <indexterm> - <primary>Hardware</primary> - </indexterm> - - <para>&os; läuft auf einer Vielzahl von ISA-, VLB-, EISA- - und PCI-Bussystemen mit Intel-, AMD-, Cyrix- oder - NexGen-Prozessoren (x86-Prozessoren). &os; läuft - auch auf einigen Compaq-Maschinen mit Alpha-Prozessoren. - &os; unterstützt IDE- oder ESDI-Laufwerke, verschiedene - SCSI-Controller, PCMCIA-Karten, USB-Geräte, Netzwerkkarten - und serielle Karten. Der Microchannel-Bus (MCA) von IBM wird - ebenfalls unterstützt.</para> - - <para>Die Hardware-Notes, die mit jedem &os;-Release - ausgeliefert werden, enthalten eine Liste lauffähiger - Hardware. Die Hardware-Notes befinden sich üblicherweise - in der Datei <filename>HARDWARE.TXT</filename> im - Wurzelverzeichnis der Distribution (CD-ROM oder FTP). - Sie können die Hardware-Notes ebenfalls im - Dokumentationsmenü von <application>sysinstall</application> - oder auf der Webseite - <ulink url="&url.base;/de/releases/index.html">Release Information</ulink> - lesen.</para> - </sect1> - <sect1 id="install-trouble"> <title>Fehlersuche</title> @@ -5225,7 +5124,6 @@ Please press any key to reboot.</screen> <surname>Vaschetto</surname> <contrib>Beigetragen von </contrib> </author> - <!-- May 2001 --> </authorgroup> </sect1info> @@ -5477,7 +5375,8 @@ Please press any key to reboot.</screen> </table> <table frame="none"> - <title>FreeBSD 5.<replaceable>X</replaceable>-ISO-Abbilder</title> + <title>FreeBSD 5.<replaceable>X</replaceable> sowie + 6.<replaceable>X</replaceable>-ISO-Abbilder</title> <tgroup cols="2"> <thead> @@ -5501,13 +5400,6 @@ Please press any key to reboot.</screen> </row> <row> - <entry><filename><replaceable>Version</replaceable>-RELEASE-<replaceable>Architektur</replaceable>-miniinst.iso</filename></entry> - - <entry>Alles, was Sie für die Installation von - von FreeBSD benötigen.</entry> - </row> - - <row> <entry><filename><replaceable>version</replaceable>-RELEASE-<replaceable>Architektur</replaceable>-disc1.iso</filename></entry> <entry>Alles, was Sie für die Installation von @@ -5529,18 +5421,14 @@ Please press any key to reboot.</screen> </tgroup> </table> - <para>Sie benötigen nur ein Abbild der Abbilder - <filename>mini.iso</filename> und + <para>Sie benötigen nur eines der beiden Abbilder + <filename>mini.iso</filename> (falls es für Ihre + &os;-Version verfügbar ist) oder <filename>disc1.iso</filename>. Laden Sie bitte nicht beide Abbilder herunter, das <filename>disc1.iso</filename>-Abbild enthält alles, was das <filename>mini.iso</filename>-Abbild enthält.</para> - <note> - <para>Das miniinst-ISO-Abbild ist nur für &os;-Versionen - vor 5.4-RELEASE verfügbar.</para> - </note> - <para>Benutzen Sie das <filename>miniinst.iso</filename>-Abbild, wenn Sie eine preiswerte Internet-Anbindung besitzen. Mit diesem Abbild können Sie &os; installieren. diff --git a/de_DE.ISO8859-1/books/handbook/mirrors/chapter.sgml b/de_DE.ISO8859-1/books/handbook/mirrors/chapter.sgml index 8979e5ba8e..c8c7cd10fd 100644 --- a/de_DE.ISO8859-1/books/handbook/mirrors/chapter.sgml +++ b/de_DE.ISO8859-1/books/handbook/mirrors/chapter.sgml @@ -3,8 +3,8 @@ The FreeBSD German Documentation Project $FreeBSD$ - $FreeBSDde: de-docproj/books/handbook/mirrors/chapter.sgml,v 1.118 2006/12/05 10:35:07 jkois Exp $ - basiert auf: 1.421 + $FreeBSDde: de-docproj/books/handbook/mirrors/chapter.sgml,v 1.119 2007/01/04 16:32:50 jkois Exp $ + basiert auf: 1.422 --> <appendix id="mirrors"> @@ -80,7 +80,7 @@ <listitem> <address> - <otheraddr>Hinner EDV</otheraddr> + <otheraddr>Dr. Hinner EDV</otheraddr> <street>St. Augustinus-Str. 10</street> <postcode>D-81825</postcode> <city>München</city> <country>Germany</country> diff --git a/de_DE.ISO8859-1/books/handbook/security/chapter.sgml b/de_DE.ISO8859-1/books/handbook/security/chapter.sgml index f17c18e114..6d0ab3ccd2 100644 --- a/de_DE.ISO8859-1/books/handbook/security/chapter.sgml +++ b/de_DE.ISO8859-1/books/handbook/security/chapter.sgml @@ -3,8 +3,8 @@ The FreeBSD German Documentation Project $FreeBSD$ - $FreeBSDde: de-docproj/books/handbook/security/chapter.sgml,v 1.149 2006/12/12 19:23:25 jkois Exp $ - basiert auf: 1.308 + $FreeBSDde: de-docproj/books/handbook/security/chapter.sgml,v 1.152 2007/01/06 09:37:57 jkois Exp $ + basiert auf: 1.311 --> <chapter id="security"> diff --git a/de_DE.ISO8859-1/books/handbook/vinum/chapter.sgml b/de_DE.ISO8859-1/books/handbook/vinum/chapter.sgml index a5ba3cc659..4de1a17434 100644 --- a/de_DE.ISO8859-1/books/handbook/vinum/chapter.sgml +++ b/de_DE.ISO8859-1/books/handbook/vinum/chapter.sgml @@ -1,31 +1,1619 @@ -<!-- - The FreeBSD Documentation Project - The FreeBSD German Documentation Project - - $FreeBSD$ - $FreeBSDde: de-docproj/books/handbook/vinum/chapter.sgml,v 1.5 2004/08/22 17:13:30 mheinen Exp $ - basiert auf: ---> - -<chapter id="vinum-vinum"> - - <title>Vinum (noch nicht übersetzt)</title> - - <para>Dieses Kapitel ist noch nicht übersetzt. - Lesen Sie bitte <ulink - url="&url.books.handbook.en;/vinum-vinum.html"> - das Original in englischer Sprache</ulink>. Wenn Sie helfen - wollen, dieses Kapitel zu übersetzen, senden Sie bitte - eine E-Mail an die Mailingliste &a.de.translators;.</para> -</chapter> - -<!-- - Local Variables: - mode: sgml - sgml-declaration: "../chapter.decl" - sgml-indent-data: t - sgml-omittag: nil - sgml-always-quote-attributes: t - sgml-parent-document: ("../book.sgml" "part" "chapter") - End: ---> +<!--
+ 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.12 2007/01/06 10:14:54 jkois Exp $
+ basiert auf: 1.41
+-->
+
+<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>Eine Möglichkeit, derartige Probleme zu
+ lösen, ist der Einsatz von mehreren, manchmal auch
+ redundant ausgelegten Platten.</para>
+
+ <para>Parallel zur Unterstützung verschiedener
+ Erweiterungskarten und Controller für Hardware-RAID-Systeme
+ enthält das FreeBSD-Basissystem auch den Vinum
+ Volume Manager, einen Blockgerätetreiber, der die
+ Einrichtung virtueller Platten unterstützt.</para>
+
+ <para>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 FreeBSD 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>/dev/gvinum</filename> statt unter
+ <filename>/dev/vinum</filename>. Seit FreeBSD 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>Bei <emphasis>Vinum</emphasis> handelt es sich um einen
+ sogenannten <emphasis>Volume Manager</emphasis>, einen
+ virtuellen Plattentreiber, der zur Lösung der im
+ letzten Abschnitt genannten Probleme entwickelt wurde.
+ Um diese Probleme zu lösen, wurden verschiedene
+ Techniken vorgeschlagen und auch implementiert.</para>
+
+ <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>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 die 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 FreeBSD-&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>/dev/gvinum</filename>-Hierarchie zugewiesen. Die
+ weiter oben dargestellte Konfiguration würde Vinum dazu
+ veranlassen, die folgenden Gerätedateien zu erstellen:</para>
+
+ <itemizedlist>
+ <listitem>
+ <note><para>Dies trifft nur für die veraltete
+ Vinum-Implementierung zu.</para></note>
+
+ <para>Die Kontrollgeräte
+ <filename>/dev/vinum/control</filename> und
+ <filename>/dev/vinum/controld</filename>, welche von
+ &man.gvinum.8; beziehungsweise dem Vinum-Daemon
+ verwendet werden.</para>
+ </listitem>
+
+ <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>/dev/gvinum/myvol</filename>,
+ <filename>/dev/gvinum/mirror</filename>,
+ <filename>/dev/gvinum/striped</filename>,
+ <filename>/dev/gvinum/raid5</filename> sowie
+ <filename>/dev/gvinum/raid10</filename>.</para>
+ </listitem>
+
+ <listitem>
+ <note><para>Dies trifft nur für die veraltete
+ Vinum-Implementierung zu.</para></note>
+
+ <para>Ein Verzeichnis <filename>/dev/vinum/drive</filename>
+ mit Einträgen für jede Platte. Diese
+ Einträge sind tatsächlich symbolische Links auf
+ die korrespondierenden Plattendateien.</para>
+ </listitem>
+
+ <listitem>
+ <para>Alle Volumes bekommen direkte Einträge unter
+ <filename>/dev/gvinum/</filename>.</para>
+ </listitem>
+
+ <listitem>
+ <para>Die Verzeichnisse
+ <filename>/dev/gvinum/plex</filename> und
+ <filename>/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>/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>/dev/ad0a</filename> oder
+ <filename>/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>/dev/gvinum/concat</filename> heißen, ein Name,
+ der in keiner Beziehung mit einem Partitionsnamen steht.</para>
+
+ <para>Normalerweise interpretiert &man.newfs.8; den Namen einer
+ Platte und beschwert sich, wenn es ihn nicht versteht:</para>
+
+ <screen>&prompt.root; <userinput>newfs /dev/gvinum/concat</userinput>
+newfs: /dev/gvinum/concat: can't figure out file system partition</screen>
+
+ <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>
+
+ <note><para>Bei &os;-Versionen vor 5.0 benötigt
+ &man.newfs.8; ein zusätzliches -v Flag und
+ das alte Gerätenamen-Schema:</para>
+ </note>
+
+ <screen>&prompt.root; <userinput>newfs -v /dev/vinum/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>Diese Information bezieht sich nur auf die veraltete
+ Vinum-Implementierung. <emphasis>Gvinum</emphasis>
+ unterstützt eine automatische Inbetriebnahme immer,
+ wenn das Kernelmodul geladen ist.</para>
+ </note>
+
+ <para>Um Vinum automatisch zu starten, wenn Sie Ihr System
+ starten, müssen Sie sicherstellen, dass Ihre
+ <filename>/etc/rc.conf</filename> (die in &man.rc.conf.5;
+ ausführlich beschrieben wird) folgende Zeile
+ enthält:</para>
+
+ <programlisting>start_vinum="YES" # set to YES to start vinum</programlisting>
+
+ <para>Durch diesen Eintrag wird das Vinum-<acronym>kld</acronym>
+ geladen, das alle Objekte startet, die in der Konfiguration
+ erwähnt werden. All dies wird vor dem Mounten der
+ Dateisysteme getan, so dass ein automatisches &man.fsck.8;
+ und Mounten der Dateisysteme auf Vinum-Volumes möglich
+ ist.</para>
+
+ <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>
+ <note>
+ <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. Der folgende Text
+ dokumentiert das Verhalten des ursprünglichen
+ Vinum-Systems.</para>
+ </note>
+
+ <para>Vinum muss früh initialisiert werden, weil es
+ das Volume für das Root-Dateisystem bereitstellen
+ muss. In der Voreinstellung sucht das
+ Vinum-Kernelmodul nicht nach Laufwerken, die vielleicht
+ Vinum-Volumeninformationen enthalten könnten,
+ bis der Administrator (oder eines der Startskripte)
+ den Befehl <command>vinum start</command>
+ ausführt.</para>
+
+ <note>
+ <para>Der folgende Absatz gibt einen Überblick
+ über die nötigen Schritte für FreeBSD 5.X
+ und neuer. Die Einrichtung unter FreeBSD 4.X
+ unterscheidet sich von dieser Vorgehensweise und wird in
+ <xref linkend="vinum-root-4x"> beschrieben.</para>
+ </note>
+
+ <para>Durch Aufnahme der Zeile</para>
+
+ <programlisting>vinum.autostart="YES"</programlisting>
+
+ <para>in <filename>/boot/loader.conf</filename>wird Vinum
+ beim Starten des Kernels dazu veranlasst, automatisch alle
+ Platten nach Vinuminformationen zu scannen.</para>
+
+ <para>Beachten Sie, dass es nicht nötig ist, den Kernel
+ davon zu unterrichten, wo er nach dem Root-Dateisystem
+ suchen soll. <filename>/boot/loader</filename> holt sich
+ den Namen des Root-Gerätes aus
+ <filename>/etc/fstab</filename> und übergibt diesen
+ dann dem Kernel. Sobald es Zeit wird, das Root-Dateisystem
+ zu mounten, findet der Kernel anhand des Gerätenamens
+ heraus, welchen Treiber er fragen muss, um den Namen in die
+ interne Geräte-ID zu übersetzen
+ (major/minor-Nummer).</para>
+ </listitem>
+ </itemizedlist>
+ </sect2>
+
+ <sect2>
+ <title>Ein Vinum-basiertes Root-Volume dem Bootstrap
+ verfügbar machen</title>
+
+ <para>Da der aktuelle FreeBSD-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>/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>/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>
+
+ <sect2 id="vinum-root-4x">
+ <title>Vinum und FreeBSD 4.X</title>
+
+ <para>Unter FreeBSD 4.X fehlen einige interne Funktionen,
+ daher ist Vinum hier nicht in der Lage, automatisch alle
+ Platten zu scannen. Außerdem ist der Code zur Bestimmung
+ der internen ID des Root-Geräts nicht intelligent genug,
+ um von sich aus mit einem Namen wie
+ <filename>/dev/vinum/root</filename> umzugehen. Dieser
+ Abschnitt beschreibt, wie Sie diese Einschränkungen
+ umgehen können.</para>
+
+ <para>Sie müssen Vinum explizit mitteilen, welche
+ Laufwerke gescannt werden sollen. Dazu nehmen Sie eine Zeile
+ ähnlich der folgenden in
+ <filename>/boot/loader.conf</filename> auf:</para>
+
+ <programlisting>vinum.drives="/dev/<replaceable>da0</replaceable> /dev/<replaceable>da1</replaceable>"</programlisting>
+
+ <para>Es ist wichtig, dass Sie alle Laufwerke angeben, die
+ Vinum-Daten enthalten könnten. Zwar schadet es nicht,
+ <emphasis>weitere</emphasis> Laufwerke anzugeben, dies ist
+ aber nicht nötig, da jedes Slice und/oder jede
+ Partition von Vinum automatisch auf gültige Vinum-Header
+ hin überprüft wird.</para>
+
+ <para>Da die Routinen, die zum Parsen des
+ Root-Dateisystems-Namens und zum Herleiten der
+ Geräte-ID (<foreignphrase>major/minor
+ number</foreignphrase>) verwendet werden, nur
+ <quote>klassische</quote> Gerätenamen verstehen,
+ ist es nicht möglich, für das Root-Volume einen
+ Namen wie <filename>/dev/vinum/root</filename> zu
+ verwenden. Daher muss Vinum den internen
+ Kernelparameter, der die ID des Root-Gerätes bekommt,
+ während seiner eigenen Initialsierung selbst
+ festlegen und den Namen des Root-Volumes der
+ Loader-Variable <literal>vinum.root</literal> übergeben.
+ Dazu wird folgende Zeile in
+ <filename>/boot/loader.conf</filename> aufgenommen:</para>
+
+ <programlisting>vinum.root="root"</programlisting>
+
+ <para>Sobald jetzt die Kernelinitialisierung versucht, den
+ Namen des zu mountenden Root-Gerätes herauszufinden, sieht
+ sie, dass ein Kernelmodul den Kernelparameter schon
+ vorinitialisiert hat. Wenn dies der Fall ist
+ <emphasis>und</emphasis> das Gerät, dass sich als
+ Root-Gerät ausgibt, tatsächlich die Hauptnummer des
+ Treibers hat, wie sie mit Hilfe des übergebenen
+ Root-Geräte-Namens (in unserem Fall ist das
+ <literal>"vinum"</literal>) ermittelt wurde, wird die
+ Kernelinitialisierung die vorbelegte Geräte-ID verwenden,
+ anstatt selbst eine herauszufinden. Auf diese Art kann es,
+ während des gewöhnlichen automatischen Hochfahrens,
+ mit dem Einhängen des Vinum-Root-Volumes als Root-Dateisystem
+ fortfahren.</para>
+
+ <para>Obwohl <command>boot -a</command> zur manuellen Eingabe
+ des Root-Gerätes auffordert, muss dennoch beachtet
+ werden, dass die Routine noch nicht in der Lage
+ ist, einen Vinum-Namen zu parsen. Wenn ein Gerätename
+ eingegeben wird, der nicht auf ein Vinum-Gerät verweist,
+ wird der Unterschied zwischen den Hauptnummern des vorbelegten
+ Root-Parameters und des Treibers die Routine dazu veranlassen,
+ den normalen Parser zu benutzen. Demnach wird eine Zeichenkette
+ wie <literal>ufs:da0d</literal> erwartungsgemäß
+ funktionieren. Beachten Sie aber, dass es im Falle eines
+ Fehlschlags nicht mehr möglich ist, eine Zeichenkette wie
+ <literal>ufs:vinum/root</literal> noch einmal einzugeben, da
+ diese nicht geparsed werden kann. Der einzige Ausweg ist dann
+ ein Neustart des Systems. (Am <quote>askroot</quote>-Prompt kann
+ der Teil <filename>/dev/</filename> des Namens der
+ Gerätedatei immer weggelassen werden.).</para>
+ </sect2>
+ </sect1>
+</chapter>
+
+<!--
+ Local Variables:
+ mode: sgml
+ sgml-declaration: "../chapter.decl"
+ sgml-indent-data: t
+ sgml-omittag: nil
+ sgml-always-quote-attributes: t
+ sgml-parent-document: ("../book.sgml" "part" "chapter")
+ End:
+-->
diff --git a/de_DE.ISO8859-1/share/sgml/glossary/freebsd-glossary.sgml b/de_DE.ISO8859-1/share/sgml/glossary/freebsd-glossary.sgml index 22fd1e15d7..bc97e8d6fd 100644 --- a/de_DE.ISO8859-1/share/sgml/glossary/freebsd-glossary.sgml +++ b/de_DE.ISO8859-1/share/sgml/glossary/freebsd-glossary.sgml @@ -29,8 +29,8 @@ des Haupttextes zu vermeiden. $FreeBSD$ - $FreeBSDde: de-docproj/share/sgml/glossary/freebsd-glossary.sgml,v 1.9 2006/01/14 08:30:13 jkois Exp $ - basiert auf: 1.24 + $FreeBSDde: de-docproj/share/sgml/glossary/freebsd-glossary.sgml,v 1.10 2007/01/04 16:49:31 jkois Exp $ + basiert auf: 1.25 --> <glossary status="draft" id="freebsd-glossary"> @@ -1032,8 +1032,8 @@ <acronym>MTA</acronym> war von jeher im BSD-Basissystem enthalten. Aktuell handelt es sich dabei um Sendmail. Es exisitieren aber auch zahlreiche andere - <acronym>MTAs</acronym>, darunter postfix, qmail und - Exim.</para> + <acronym>MTA</acronym>s, darunter postfix, qmail und + Exim.</para> </glossdef> </glossentry> |