From 9eae7b08fbd53f9435a130853f19ee1b3d5165be Mon Sep 17 00:00:00 2001 From: Bjoern Heidotting Date: Sun, 9 Aug 2015 16:38:38 +0000 Subject: [PATCH] Update to r42118: Remove the vinum chapter. It has been surpassed by other solutions from GEOM and ZFS. The existing version is archived in http://docs.freebsd.org/doc/ . Illustration images in doc/share/images/books/handbook/vinum/ remain, as they are used by non-English translations. -doc mailing list discussion thread: http://lists.freebsd.org/pipermail/freebsd-doc/2013-June/022216.html Approved by: bcr (mentor) --- de_DE.ISO8859-1/books/handbook/Makefile | 2 +- de_DE.ISO8859-1/books/handbook/book.xml | 3 +- de_DE.ISO8859-1/books/handbook/chapters.ent | 3 +- .../books/handbook/disks/chapter.xml | 8 +- .../books/handbook/preface/preface.xml | 20 +- .../books/handbook/vinum/chapter.xml | 1419 ----------------- 6 files changed, 5 insertions(+), 1450 deletions(-) delete mode 100644 de_DE.ISO8859-1/books/handbook/vinum/chapter.xml diff --git a/de_DE.ISO8859-1/books/handbook/Makefile b/de_DE.ISO8859-1/books/handbook/Makefile index ad6d4af892..1896a597fa 100644 --- a/de_DE.ISO8859-1/books/handbook/Makefile +++ b/de_DE.ISO8859-1/books/handbook/Makefile @@ -1,7 +1,7 @@ # # $FreeBSD$ # $FreeBSDde: de-docproj/books/handbook/Makefile,v 1.67 2011/12/31 12:27:25 bcr Exp $ -# basiert auf: 42118 +# basiert auf: r42118 # # Build the FreeBSD Handbook in its German translation. # diff --git a/de_DE.ISO8859-1/books/handbook/book.xml b/de_DE.ISO8859-1/books/handbook/book.xml index 8ee712d416..6ae8213d6e 100644 --- a/de_DE.ISO8859-1/books/handbook/book.xml +++ b/de_DE.ISO8859-1/books/handbook/book.xml @@ -7,7 +7,7 @@ $FreeBSD$ $FreeBSDde: de-docproj/books/handbook/book.xml,v 1.91 2012/03/27 19:32:11 bcr Exp $ - basiert auf: 45698 + basiert auf: r42118 --> %chapters; %txtfiles; @@ -255,7 +255,6 @@ &chap.geom; &chap.zfs; &chap.filesystems; - &chap.vinum; &chap.virtualization; &chap.l10n; &chap.cutting-edge; diff --git a/de_DE.ISO8859-1/books/handbook/chapters.ent b/de_DE.ISO8859-1/books/handbook/chapters.ent index c6a155985d..5257a2456a 100644 --- a/de_DE.ISO8859-1/books/handbook/chapters.ent +++ b/de_DE.ISO8859-1/books/handbook/chapters.ent @@ -10,7 +10,7 @@ $FreeBSD$ $FreeBSDde: de-docproj/books/handbook/chapters.ent,v 1.34 2011/10/08 16:47:33 jkois Exp $ - basiert auf: 43126 + basiert auf: r42118 --> @@ -45,7 +45,6 @@ - diff --git a/de_DE.ISO8859-1/books/handbook/disks/chapter.xml b/de_DE.ISO8859-1/books/handbook/disks/chapter.xml index 12f9934a65..8fbcc0d4bf 100644 --- a/de_DE.ISO8859-1/books/handbook/disks/chapter.xml +++ b/de_DE.ISO8859-1/books/handbook/disks/chapter.xml @@ -5,7 +5,7 @@ $FreeBSD$ $FreeBSDde: de-docproj/books/handbook/disks/chapter.xml,v 1.187 2012/04/26 19:32:48 bcr Exp $ - basiert auf: r42018 + basiert auf: r42118 --> Speichermedien @@ -3156,12 +3156,6 @@ gbde_lockdir="/etc/gbde" &prompt.root; gbde detach /dev/ad4s1c - - Sie können gbde - nicht zusammen mit vinum - benutzen, da &man.vinum.4; das &man.geom.4;-Subsystem - nicht benutzt. - diff --git a/de_DE.ISO8859-1/books/handbook/preface/preface.xml b/de_DE.ISO8859-1/books/handbook/preface/preface.xml index addd049655..6f18a5d170 100644 --- a/de_DE.ISO8859-1/books/handbook/preface/preface.xml +++ b/de_DE.ISO8859-1/books/handbook/preface/preface.xml @@ -5,7 +5,7 @@ $FreeBSD$ $FreeBSDde: de-docproj/books/handbook/preface/preface.xml,v 1.36 2011/12/24 13:06:39 bcr Exp $ - basiert auf: r41912 + basiert auf: r42118 --> Vorwort @@ -105,15 +105,6 @@ abgesichert werden können. - - , Vinum, ist ebenfalls ein - neues Kapitel in dieser Auflage. Dieses Kapitel beschreibt - den Logical-Volume-Manager Vinum, der - geräteunabhängige logische Platten und - RAID-0, RAID-1 sowie RAID-5 auf Software-Ebene - bereitstellt. - - Zum Kapitel , PPP und SLIP, wurde ein Abschnitt über Fehlersuche @@ -519,15 +510,6 @@ - - , Vinum - - Beschreibt den Vinum Volume Manager, der virtuelle Laufwerke, - RAID-0, RAID-1 und RAID-5 auf Software-Ebene - bereitstellt. - - - , Virtualisierung diff --git a/de_DE.ISO8859-1/books/handbook/vinum/chapter.xml b/de_DE.ISO8859-1/books/handbook/vinum/chapter.xml deleted file mode 100644 index 7f49618c04..0000000000 --- a/de_DE.ISO8859-1/books/handbook/vinum/chapter.xml +++ /dev/null @@ -1,1419 +0,0 @@ - - - - Der Vinum Volume Manager - - GregLeheyUrsprünglich geschrieben von - - - JohannKoisÜbersetzt von - KayAbendroth - - - - - - - Übersicht - - - Egal, über welche und wieviele Festplatten Ihr System - auch verfügt, immer wieder werden Sie mit den folgenden - Problemen konfrontiert: - - - - Ihre Platten sind zu klein. - - - - Sie sind zu langsam. - - - - Ihre Platten sind unzuverlässig. - - - - 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 - Vinum handelt es sich um einen - sogenannten Volume Manager, 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). - - Dieses Kapitel bietet Ihnen einen Überblick über - potentielle Probleme der klassischen Datenspeicherung auf - Festplatten sowie eine Einführung in den Vinum - Volume Manager. - - - Für &os; 5.X wurde Vinum überarbeitet und - an die GEOM-Architektur () angepasst, - wobei die ursprünglichen Ideeen und Begriffe sowie die - auf der Platte benötigten Metadaten beibehalten wurden. - Die überarbeitete Version wird als - gvinum (für - GEOM-Vinum) bezeichnet. Die folgenden - Ausführungen verwenden den Begriff - Vinum als abstrakten Namen, unabhängig - davon, welche Variante implementiert wurde. Sämtliche - Befehlsaufrufe erfolgen über gvinum, - welches nun das Kernelmodul geom_vinum.ko - (statt vinum.ko) benötigt. Analog - finden sich alle Gerätedateien nun unter /dev/gvinum statt unter /dev/vinum. Seit &os; 6.x ist die - alte Vinum-Implementierung nicht mehr im Basissystem enthalten. - - - - - Ihre Platten sind zu klein. - - Vinum - - RAID - Software - - - 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. - - - - Mögliche Engpässe - - 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. - - 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. - - 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. - - 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. - - Die traditionelle und offensichtliche Lösung zur - Beseitigung dieses Flaschenhalses sind mehr - Spindeln. 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. - - 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. - - - Plattenkonkatenation - - - Vinum - Konkatenation - - - 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 - Konkatenation 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. - verdeutlicht die Verteilung der - Speichereinheiten in einer konkatenierten Anordnung. - - -
- Konkatenierte Anordnung - -
- - - - Striping von Platten - - - Vinum - Striping - - - RAID - - - 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 Striping oder - RAID-0. - - RAID steht für Redundant - Array of Inexpensive Disks und bietet verschiedene - Formen der Fehlertorleranz, obwohl der letzte Begriff etwas - irreführend ist, da RAID keine Redundanz bietet. - - - 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. veranschaulicht - die Abfolge, in der Speichereinheiten in einer striped-Anordnung - alloziert werden. - - -
- Striped-Anordnung - -
- - - - - Datenintegrität - - 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. - - - disk mirroring - - - Vinum - Spiegelung - - - RAID-1 - - - Die traditionelle Art, dieses Problem anzugehen, war es, - Daten zu spiegeln, also zwei Kopien der - Daten auf getrennten Platten zu verwahren. Diese Technik wird - auch als RAID Level 1 oder - RAID-1 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. - - Spiegeln verursacht allerdings zwei Probleme: - - - - Es verursacht höhere Kosten, da doppelt so viel - Plattenspeicher wie bei einer nicht-redundanten - Lösung benötigt wird. - - - - 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. - - - - RAID-5 - - Eine alternative Lösung ist - Parity, das in den - RAID-Leveln 2, 3, 4 und 5 - implementiert ist. Von diesen ist RAID-5 - 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 RAID-5 - vorgeschrieben, ist die Position dieses Paritätsblockes - auf jedem Stripe unterschiedlich. Die Nummern in den - Datenblöcken geben die relativen Blocknummern an. - - -
- RAID-5 Aufbau - -
- - - 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. - - - - Vinum-Objekte - Um die in den vorigen Abschnitte besprochenen Probleme zu - lösen, verwendet Vinum eine vierstufige - Objekthierarchie: - - - - Das auffälligste Objekt ist die virtuelle Platte, - die Volume 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. - - - - Volumes bestehen aus einem oder mehreren - Plexus, - 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. - - - - 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 - Platte) in zusammenhängende - Bereiche, die als Subdisks bezeichnet - werden und als Grundbausteine für einen Plexus - benutzt werden. - - - - Subdisks befinden sich auf - Vinum-Platten, 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. - - - - Der folgende Abschnitt beschreibt, wie diese Objekte - die von Vinum benötigten Funktionen zur - Verfügung stellen. - - - Überlegungungen zur Größe eines Volumes - - 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. - - - - Redundante Datenspeicherung - - 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. - - 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. - - - - Überlegungen zur Leistung - - Sowohl Konkatenation als auch Striping werden von Vinum - auf der Plexus-Ebene realisiert: - - - - Ein konkatenierter Plexus benutzt - abwechselnd den Adressraum jeder Subdisk. - - - - Ein gestripter Plexus 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. - - - - - - Wie ist ein Plexus aufgebaut? - - Die Version von Vinum, welche von &os;-&rel.current; - bereitgestellt wird, implementiert zwei Arten von Plexus: - - - - 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 - CPU-Zeit als gestripte Plexus, obwohl - der Unterschied des CPU-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. - - - - Der größte Vorteil eines gestripten - Plexus (RAID-0) 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. - - - - fasst die Vor- und - Nachteile jedes Plexus-Aufbaus zusammen. - - - Vinum-Plexus - Aufbau - - - - - Plexus-Typ - Minimum an Subdisks? - Kann Subdisks hinzufügen? - Müssen die gleiche Größe - haben - Applikation - - - - - - konkateniert - 1 - ja - nein - Großer Datenspeicher mit maximaler - Platzierungsflexibilität und moderater - Leistung - - - - gestriped - 2 - nein - ja - Hohe Leistung in Kombination mit - gleichzeitigem Zugriff - - - -
- - - - - Einige Beispiele - - Vinum verwaltet eine - Konfigurationsdatenbank 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 Device - bezeichnet). Da die Datenbank bei jedem Statuswechsel - aktualisiert wird, kann nach einem Neustart der Status - jedes Vinum-Objekts exakt wiederhergestellt werden. - - - Die Konfigurationsdatei - - Die Konfigurationsdatei beschreibt individuelle - Vinum-Objekte. Die Beschreibung eines einfachen Volumes - könnte beispielsweise so aussehen: - - - drive a device /dev/da3h - volume myvol - plex org concat - sd length 512m drive a - - Diese Datei beschreibt vier Vinum-Objekte: - - - - Die drive-Zeile beschreibt eine - Plattenpartition (drive) sowie ihre - Position in Bezug auf die darunter liegende Hardware. - Die Partition hat dabei den symbolischen Namen - a. Diese Trennung von symbolischen - Namen und Gerätenamen erlaubt es, die Position von - Platten zu ändern, ohne dass es zu Problemen - kommt. - - - - Die volume-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 myvol. - - - - Die plex-Zeile definiert einen - Plexus. Auch hier wird nur ein Parameter, und zwar die - Art des Aufbau, benötigt (in unserem Fall - concat). Es wird kein Name - benötigt, das System generiert automatisch einen - Namen aus dem Volume-Namen und dem Suffix - .px wobei - x die Nummer des Plexus innerhalb - des Volumes angibt. So wird dieser Plexus den Namen - myvol.p0 erhalten. - - - - Die sd-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 .sx - gebildet werden, wobei x die Nummer - der Subdisk innerhalb des Plexus ist. Folglich gibt - Vinum dieser Subdisk den Namen - myvol.p0.s0. - - - - Nach dem Verarbeiten dieser Datei erzeugt &man.gvinum.8; - die folgende Ausgabe: - - - &prompt.root; gvinum -> create config1 - 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 - - Diese Ausgabe entspricht dem verkürzten - Ausgabeformat von &man.gvinum.8; und wird in - grafisch dargestellt. - - -
- Ein einfaches Vinum-Volume - -
- - - 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. - - 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. - - - - Verbesserte Ausfallsicherheit durch Spiegelung - - 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: - - - drive b device /dev/da4h - volume mirror - plex org concat - sd length 512m drive a - plex org concat - sd length 512m drive b - - Bei diesem Beispiel war es nicht nötig, noch einmal - eine Platte a 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: - - - 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 - - stellt diese Struktur - grafisch dar. - - -
- Ein gespiegeltes Vinum Volume - -
- - - In diesem Beispiel enthält jeder Plexus die vollen - 512 MB des Adressraumes. Wie im vorangegangenen Beispiel - enthält jeder Plexus nur eine Subdisk. - - - - Die Leistung optimieren - - 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: - - - 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 - - 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: - - - 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 - - -
- Ein Striped Vinum Volume - -
- - - Dieses Volume wird in - dargestellt. Die Schattierung der Stripes zeigt die Position - innerhalb des Plexus-Adressraumes an. Die hellsten Stripes - kommen zuerst, die dunkelsten zuletzt. - - - - Ausfallsicherheit und Leistung - - 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: - - - 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 - - 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. - - veranschaulicht die - Struktur dieses Volumes. - - -
- Ein gespiegeltes, Striped Vinum Volume - -
- - - - - - Objektbenennung - - 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. - - 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. - - Vinum-Objekten werden Gerätedateien in der /dev/gvinum-Hierarchie zugewiesen. Die - weiter oben dargestellte Konfiguration würde Vinum dazu - veranlassen, die folgenden Gerätedateien zu erstellen: - - - - 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: - /dev/gvinum/myvol, - /dev/gvinum/mirror, - /dev/gvinum/striped, - /dev/gvinum/raid5 sowie - /dev/gvinum/raid10. - - - - Alle Volumes bekommen direkte Einträge unter /dev/gvinum/. - - - - Die Verzeichnisse /dev/gvinum/plex und /dev/gvinum/sd, die Gerätedateien - für jeden Plexus sowie jede Subdisk enthalten. - - - - Stellen Sie sich folgende Konfigurationsdatei vor: - - - 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 - - Nach Abarbeitung dieser Datei erstellt &man.gvinum.8; die - folgende Struktur unter /dev/gvinum: - - - 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 - - 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. - - - Dateisysteme erstellen - - 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 - /dev/ad0a oder - /dev/da2h haben. Diese Namen - bedeuten, dass es sich um die erste Partition - (a) der ersten (0) IDE-Platte - (ad) und respektive die achte - Partition (h) der dritten (2) - SCSI-Platte (da) handelt. Im Vergleich - dazu könnte ein Vinum-Volume beispielsweise /dev/gvinum/concat heißen, ein Name, - der in keiner Beziehung mit einem Partitionsnamen steht. - - Um nun ein Dateisystem auf diesem Volume anzulegen, benutzen - Sie &man.newfs.8;: - - &prompt.root; newfs /dev/gvinum/concat - - - - - Vinum konfigurieren - - Der GENERIC-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 kld) 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. - - - Inbetriebnahme - - 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: - - 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 - - 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. - - - Automatische Inbetriebnahme - - - Gvinum - unterstützt eine automatische Inbetriebnahme immer, - wenn das Kernelmodul über &man.loader.conf.5; geladen ist. - Um das Gvinum Modul beim Hochfahren des - Systems zu laden, fügen Sie die Zeile - geom_vinum_load="YES" in - /boot/loader.conf ein. - - - Beim starten von Vinum durch den Befehl vinum - start 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. - - - - - - Vinum für das Root-Dateisystem benutzen - - Auf einem System, das mit Hilfe von Vinum - vollgespiegelte Dateisysteme hat, ist es wünschenswert, auch - das Root-Dateisystem zu spiegeln. Solch eine Konfiguration ist - allerdings weniger trivial als das Spiegeln eines - gewöhnlichen Dateisystems, weil: - - - - Das Root-Dateisystem in einer sehr frühen Phase - des Bootvorgangs verfügbar sein muss, und damit auch - die Vinum-Infrastruktur. - - - - Das Volume, welches das Root-Dateisystem enthält, - auch den Bootstrap und den Kernel enthält, die - wiederum nur mit den systemeigenen Tools (zum Beispiel - dem BIOS bei handelsüblichen PCs) gelesen werden - können und meist nicht dazu gebracht werden können, - Vinum zu verstehen. - - - - Im folgenden Abschnitt wird der Begriff - Root-Volume benutzt, um das Vinum-Volume zu - beschreiben, welches das Root-Dateisystem enthält. Es ist - eine gute Idee, für dieses Volume den Namen - "root" zu benutzen, aber es ist in keiner - Weise technisch nötig (Das folgende Beispiel geht allerdings - davon aus, dass dies der Fall ist.). - - - Vinum für das Root-Dateisystem rechtzeitig - starten - - Damit dies gelingt, müssen Sie folgende Aufgaben - erledigen: - - - - Vinum muss zum Zeitpunkt des Bootvorganges im - Kernel zur Verfügung stehen. Deswegen ist die - Methode zum Start von Vinum, die in - beschrieben wird, - für diese Aufgabe nicht geeignet. Also muss - auch der start_vinum-Parameter - eigentlich nicht gesetzt werden, - wenn man das folgende Setup einrichtet. Die erste - Möglichkeit wäre es, Vinum statisch in den - Kernel zu kompilieren, so dass es ständig - verfügbar ist, was aber in der Regel nicht - erwünscht ist. Ebenso gibt es die Möglichkeit - /boot/loader - () das Vinum-Kernelmodul - früh genug laden zu lassen (und zwar noch bevor - der Kernel gestartet wird). Dies kann bewerkstelligt - werden, indem die Zeile - - geom_vinum_load="YES" - - in die Datei /boot/loader.conf - eingetragen wird. - - - - Für Gvinum ist das oben - beschriebene Prozedere alles, was Sie tun müssen, - da der gesamte Startvorgang automatisch erledigt wird, - sobald das Kernelmodul geladen wurde. - - - - - - Ein Vinum-basiertes Root-Volume dem Bootstrap - verfügbar machen - - Da der aktuelle &os;-Bootstrap nur 7,5 KB Code - enthält und schon ohne Vinum die Aufgabe hat, - bestimmte Dateien (wie /boot/loader) - von einem UFS-Dateisystem zu lesen, ist es schier - unmöglich, ihm auch noch die Interna von Vinum - beizubringen, damit er die Vinum-Konfigurationsdaten - auslesen und die Elemente eines Boot-Volumes selbst - herausfinden könnte. Daher sind ein paar Tricks - nötig, um dem Bootstrap-Code die Illusion - einer Standard-"a"-Partition mit - einem Root-Dateisystem vorzugaukeln. - - Damit dies überhaupt möglich wird, - müssen die folgenden Bedingungen für das - Root-Dateisystem erfüllt sein: - - - - Das Root-Volume darf weder gestriped noch - RAID-5 sein. - - - - Das Root-Volume darf nicht mehr als eine konkatenierte - Subdisk pro Plexus enthalten. - - - - Beachten Sie, dass es möglich und - wünschenswert ist, mehrere Plexus zu haben, von denen - jeder eine Kopie des Root-Dateisystems enthält. Der - Bootstrap-Prozess wird hingegen nur einen dieser Plexus - benutzen, um den Bootstrap und alle Dateien zu finden, bis der - Kernel letztendlich das Root-Dateisystem selbst laden wird. - Jede einzelne Subdisk innerhalb dieser Plexus wird dann ihre - eigene Illusion der Partition "a" brauchen, - damit das entsprechende Gerät bootbar wird. Es ist nicht - unbedingt notwendig, dass sich jede dieser gefälschten - "a"-Partitionen auf seinem Gerät an - einem Ort befindet, der um den selben Wert verschoben ist wie - auf den anderen Geräten, die Plexus des Root-Dateisystems - enthalten. Um Unklarheiten zu verhindern, ist es jedoch eine - gute Idee, die Vinum-Volumes so zu erstellen, dass die - gespiegelten Geräte symmetrisch sind. - - Damit diese "a"-Partitionen eingerichtet - werden können, muss für alle Geräte, die Teil des - Root-Dateisystems sind, folgendes getan werden: - - - - Der Ort (Verschiebung vom Beginn des Gerätes) und - die Größe der Subdisk, die Teil des Root-Volumes - ist, muss untersucht werden: - - &prompt.root; gvinum l -rv root - - Beachten Sie, dass Vinum-Verschiebungen und - -Größen in Bytes gemessen werden. Sie müssen - deshalb durch 512 geteilt werden, um die Blockanzahl zu - erhalten, wie sie das bsdlabel-Kommando - verwendet. - - - - Führen Sie den Befehl - - &prompt.root; bsdlabel -e devname - - für jedes Gerät, dass am Root-Volume beteiligt - ist, aus. devname muss entweder - der Name der Platte (wie da0), im - Falle einer Platte ohne Slice-Tabelle oder der Name des - Slices (wie ad0s1) sein. - - Wenn es schon eine "a"-Partition auf - dem Gerät (in der Regel wahrscheinlich ein - Prä-Vinum-Root-Dateisystem) gibt, sollte diese - umbenannt werden, damit sie weiterhin verfügbar bleibt - (nur für den Fall). Sie wird aber nicht länger - benutzt, um das System zu starten. Beachten Sie aber, dass - aktive Partitionen (wie ein gemountetes Root-Dateisystem) - nicht umbenannt werden können, sodass Sie entweder von - einem Fixit-Medium booten müssen, oder - aber mittels eines zweistufigen Prozesses (sofern Sie in einer - gespiegelten Umgebung arbeiten) zuerst die Platte - ändern, von der gerade nicht gebootet wurde. - - Nun muss die Verschiebung der Vinum-Partition (sofern - vorhanden) auf diesem Gerät mit der Veschiebung der - entsprechenden Root-Volume-Subdisk addiert werden. Das - Resultat wird der "offset"-Wert für - die neue "a"-Partition. Der - "size"-Wert für diese Partition - kann entsprechend der Berechnung ermittelt werden. - "fstype" sollte 4.2BSD - sein. Die "fsize"-, - "bsize"-, und - "cpg"- Werte sollten entsprechend dem - eigentlichen Dateisystem gewählt werden, obwohl sie in - diesem Kontext ziemlich unwichtig sind. - - Auf diese Art und Weise wird eine neue Partition - "a" etabliert, die die Vinum-Partition - auf diesem Gerät überschneidet. Beachte Sie, dass - das bsdlabel-Kommando diese - Überschneidung nur erlaubt, wenn die Partition richtig - mit dem "vinum"-fstype markiert ist. - - - - Das ist alles. Auf jedem Gerät befindet sich nun - eine gefälschte "a"-Partition, die - eine Kopie des Root-Volumes enthält. Es wird dringend - empfohlen, das Resultat dieser Konfiguration zu - überprüfen: - - &prompt.root; fsck -n /dev/devnamea - - - - Denken Sie stets daran, dass alle Dateien, die - Kontrollinformationen enthalten, nun relativ zum - Root-Dateisystem innerhalb des Vinum-Volumes sein müssen. - Denn ein neu eingerichtetes Vinum-Root-Dateisystem ist - möglicherweise inkompatibel zum gerade aktiven - Root-Dateisystem. Deshalb müssen insbesondere die - Dateien /etc/fstab und - /boot/loader.conf überprüft - werden. - - Beim nächsten Systemstart sollte der Bootstrap die - adäquaten Kontrollinformationen des neuen - Vinum-basierten Root-Dateisystems automatisch herausfinden und - entsprechend handeln. Am Ende des - Kernel-Initialisierungsprozesses (nachdem alle Geräte - angezeigt wurden) erhalten Sie bei einer erfolgreichen - Konfiguration eine Nachricht ähnlich der folgenden: - - Mounting root from ufs:/dev/gvinum/root - - - - Beispiel eines Vinum-basierten Root-Setups - - Nachdem das Vinum-Root-Volume eingerichtet wurde, - könnte die Ausgabe von gvinum l -rv root - bespielsweise so aussehen: - - -... -Subdisk root.p0.s0: - Size: 125829120 bytes (120 MB) - State: up - Plex root.p0 at offset 0 (0 B) - Drive disk0 (/dev/da0h) at offset 135680 (132 kB) - -Subdisk root.p1.s0: - Size: 125829120 bytes (120 MB) - State: up - Plex root.p1 at offset 0 (0 B) - Drive disk1 (/dev/da1h) at offset 135680 (132 kB) - - - Wichtig ist hier insbesondere ist der Wert - 135680 für die Verschiebung (relativ zur - Partition /dev/da0h). Das entspricht - beim Einsatz von bsdlabel 265 - 512-Byte-Plattenblöcken. Dieses Root-Volume ist ebenso - 245760 512-Byte-Blöcke groß. - /dev/da1h enthält die - zweite Kopie dieses Root-Volumes und ist symmetrisch aufgebaut. - - Das Bsdlabel für diese Geräte könnte - so aussehen: - - -... -8 partitions: -# size offset fstype [fsize bsize bps/cpg] - a: 245760 281 4.2BSD 2048 16384 0 # (Cyl. 0*- 15*) - c: 71771688 0 unused 0 0 # (Cyl. 0 - 4467*) - h: 71771672 16 vinum # (Cyl. 0*- 4467*) - - - Wie man leicht feststellen kann, entspricht der Parameter - "size" der gefälschten - "a"-Partition dem ausgewiesenen Wert von - oben, während der Parameter - "offset" gleich der Summe der Verschiebung - innerhalb der Vinum-Partition "h" und der - Verschiebung innerhalb des Geräts (oder Slice) ist. Dies - ist ein typischer Aufbau, der nötig ist, um die in - beschriebenen Probleme zu - vermeiden. Die gesamte Partition "a" befindet - sich in "h", die alle Vinum-Daten für - dieses Gerät enthält. - - Beachten Sie, dass in dem oben beschriebenen Beispiel das - gesamte Gerät Vinum gewidmet ist und keine - Prä-Vinum-Partition zurückgelassen wurde, da es sich - im Beispiel um eine neu eingerichtete Platte handelt, die nur - für die Vinum-Konfiguration bestimmt war. - - - - Fehlerbehebung - - Der folgende Abschnitt beschreibt einige bekannte - Probleme und Fallstricke bei der Vinum-Konfiguration sowie - deren Behebung. - - - Der System-Bootstrap lädt zwar, das System startet - aber nicht. - - Wenn aus irgendeinem Grund das System nicht mit dem Booten - fortfährt, kann man den Bootstrap während der - 10-Sekunden-Warnung durch Drücken der - Leertaste unterbrechen. Die - loader-Variablen (wie - vinum.autostart) können mittels des - show-Kommandos untersucht, und mit - set oder unset - geändert werden. - - Wenn das einzige Problem das Fehlen des - Vinum-Kernelmoduls in der Liste der automatisch zu ladenden - Module ist, hilft ein einfaches - load geom_vinum. - - Danach können Sie den Bootvorgang mit - boot -as fortsetzen. Die Optionen - fordern den Kernel auf, nach dem zu - mountenden Root-Dateisystem zu fragen (), - und den Bootvorgang im Single-User-Modus - () zu beenden, in dem das - Root-Dateisystem schon schreibgeschützt gemountet ist. - Auf diese Weise wird keine Dateninkonsistenz zwischen den - Plexus riskiert, auch wenn nur ein Plexus eines - Multi-Plexus-Volumes gemountet wurde. - - Beim Prompt, das nach einem Root-Dateisystem fragt, - kann jedes Gerät angegeben werden, dass ein - gültiges Root-Dateisystem hat. Wenn - /etc/fstab richtig konfiguriert - wurde, sollte die Vorgabe etwas wie - ufs:/dev/gvinum/root sein. Eine typische - Alternative würde etwas wie - ufs:da0d sein, welches eine - hypothetische Partition sein könnte, die ein - Pre-Vinum-Root-Dateisystem enthält. Vorsicht sollte - walten, wenn eine der alias - "a"-Partitionen hier eingegeben wird, die - eigentlich Referenzen auf die Subdisks des - Vinum-Root-Dateisystems sind, da so nur ein Stück eines - gespiegelten Root-Gerätes gemountet werden würde. - Wenn das Dateisystem später zum Lesen und Schreiben - gemountet werden soll, ist es nötig, die anderen Plexus - des Vinum-Root-Volumes zu entfernen, weil diese Plexus - andernfalls inkonsistente Daten enthalten würden. - - - - Nur der primäre Bootstrap lädt - - Wenn das Laden von /boot/loader - fehlschlägt, aber der primäre Bootstrap dennoch - lädt (sichtbar an dem einzelnen Strich in der linken - Spalte des Bildschirms gleich nachdem der Bootprozess - startet), kann man versuchen, den primären Bootstrap - an diesem Punkt durch Benutzen der - Leertaste zu unterbrechen. Dies wird - den Bootstrap in der zweiten Phase stoppen (siehe dazu auch - ). Hier kann nun der Versuch - unternommen werden, von einer anderen Partition zu booten, - wie beispielsweise dem vorhergehenden Root-Dateisystem, - das von "a" verschoben wurde. - - - - Nichts bootet, der Bootstrap hängt sich auf - - Diese Situation wird vorkommen, wenn der Bootstrap durch - die Vinum-Installation zerstört worden ist. - Unglücklicherweise lässt Vinum am Anfang seiner - Partition nur 4 KB frei und schreibt dahinter seine - Kopfinformationen. Allerdings benötigen Stufe-Eins- - und -Zwei-Bootstraps plus dem dazwischen eingebetteten - bsdlabel momentan 8 KB. - Demzufolge wird die Vinum-Installation, wenn die - Vinum-Partition mit der Verschiebung 0 (innerhalb eines - Slice oder einer Platte, die zum Start bestimmt waren) - eingerichtet wurde, den Bootstrap zerstören. - - Analog wird eine anschließende - Reinstallation eines Bootstrap (zum Beispiel durch Booten - eines Fixit-Mediums) mit - bsdlabel -B, wie in - 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. - - - -