ZFS ist ein fundamental anderes Dateisystem aufgrund der Tatsache, dass es mehr als ein Dateisystem ist. ZFS kombiniert die Rolle eines Dateisystems mit dem Volumemanager, was es ermöglicht, zusätzliche Speichermedien zu einem laufenden System hinzuzufügen und diesen neuen Speicher sofort auf allen auf dem Pool existierenden Dateisystemen zur Verfügung zu haben. Durch die Kombination von traditionell getrennten Rollen ist ZFS in der Lage, Einschränkungen, die zuvor RAID-Gruppen daran gehindert hatten, zu wachsen. Jedes Gerät auf höchster Ebene in einem Pool wird ein vdev genannt, was eine einfache Platte oder eine RAID-Transformation wie ein Spiegel oder RAID-Z-Verbund sein kann. ZFS-Dateisysteme (datasets genannt), haben jeweils Zugriff auf den gesamten freien Speicherplatz des gesamten Pools. Wenn Blöcke aus diesem Pool allokiert werden, verringert sich auch der freie Speicherplatz für jedes Dateisystem. Dieser Ansatz verhindert die allgegenwärtige Falle von umfangreichen Partitionen, bei denen freier Speicherplatz über alle Partitionen hinweg fragmentiert wird.
zpool | Ein Speicher-Pool ist der
grundlegendste Baustein von ZFS. Ein
Pool besteht aus einem oder mehreren vdevs, was die
zugrundeliegenden Geräte repräsentiert, welche die Daten
speichern. Ein Pool wird dann verwendet, um ein oder
mehrere Dateisysteme (Datasets) oder Blockgeräte
(Volumes) zu erstellen. Diese Datasets und Volumes
teilen sich den im Pool verfügbaren Speicherplatz.
Jeder Pool wird eindeutig durch einen Namen und eine
GUID identifiziert. Die verfügbaren
Eigenschaften werden durch die
ZFS-Versionsnummer des Pools
bestimmt.
Anmerkung:FreeBSD 9.0 und 9.1 enthalten Unterstützung für ZFS Version 28. Spätere Versionen setzen ZFS Version 5000 mit Feature Flags ein. Das neue Feature Flag System erlaubt eine größere Kompatibilität mit anderen Implementierungen von ZFS. |
vdev Arten | Ein Pool besteht aus einem oder mehreren vdevs, die
selbst eine einfache Platte oder im Fall von
RAID eine Gruppe von Platten
darstellt. Wenn mehrere vdevs eingesetzt werden,
verteilt ZFS die Daten über die
vdevs, um die Geschwindigkeit zu steigern und den
verfügbaren Platz zu maximieren.
|
Transaktionsgruppe (Transaction Group, TXG) | Transaktionsgruppen sind die Art und Weise, wie
geänderte Blöcke zusammen gruppiert und letztendlich auf
den Pool geschrieben werden. Transaktionsgruppen sind
die atomare Einheit, welche ZFS
verwendet, um Konsistenz zu gewährleisten. Jeder
Transaktionsgruppe wird eine einzigartige, fortlaufende
64-Bit Identifikationsnummer zugewiesen. Es kann bis zu
drei aktive Transaktionsgruppen gleichzeitig geben,
wobei sich jede davon in einem der folgenden drei
Zustände befinden kann:
Schnappschüsse
werden als Teil einer Transaktionsgruppe geschrieben.
Wenn ein synctask erstellt ist, wird dieser der momentan
geöffneten Transaktionsgruppe hinzugefügt und diese
Gruppe wird so schnell wie möglich in den
Synchronisationszustand versetzt, um die Latenz von
administrativen Befehlen zu reduzieren. |
Adaptive Replacement Cache (ARC) | ZFS verwendet einen Adaptive Replacement Cache (ARC), anstatt eines traditionellen Least Recently Used (LRU) Caches. Ein LRU-Cache ist eine einfache Liste von Elementen im Cache, sortiert nach der letzten Verwendung jedes Elements in der Liste. Neue Elemente werden an den Anfang der Liste eingefügt. Wenn der Cache voll ist, werden Elemente vom Ende der Liste verdrängt, um Platz für aktivere Objekte zu schaffen. Ein ARC besteht aus vier Listen: derjenigen der Most Recently Used (MRU) und Most Frequently Used (MFU) Objekte, plus einer sogenannten ghost list für jede von beiden. Diese Ghost Lists verfolgen die kürzlich verdrängten Objekte, um zu verhindern, dass diese erneut in den Cache aufgenommen werden. Dies erhöht die Trefferrate (hit ratio) des Caches, indem verhindert wird, dass Elemente, die in der Vergangenheit nur ab und zu benutzt wurden, wieder im Cache landen. Ein weiterer Vorteil der Verwendung sowohl einer MRU und einer MFU ist, dass das Scannen eines gesamten Dateisystems normalerweise alle Daten aus einem MRU- oder LRU-Cache verdrängt, um dem gerade frisch zugegriffenem Inhalt den Vorzug zu geben. Mit ZFS gibt es also eine MFU, die nur die am häufigsten verwendeten Elemente beinhaltet und der Cache von am meisten zugegriffenen Blöcken bleibt erhalten. |
L2ARC | L2ARC ist die zweite Stufe des
Caching-Systems von ZFS. Der
Haupt-ARC wird im
RAM abgelegt. Da die Menge an
verfügbarem RAM meist begrenzt ist,
kann ZFS auch cache vdevs
verwenden. Solid State Disks (SSDs)
werden oft als diese Cache-Geräte eingesetzt, aufgrund
ihrer höheren Geschwindigkeit und niedrigeren Latenz im
Vergleich zu traditionellen drehenden Speichermedien wie
Festplatten. Der Einsatz des L2ARC
ist optional, jedoch wird durch die Verwendung eine
signifikante Geschwindigkeitssteigerung bei
Lesevorgängen bei Dateien erzielt, welche auf der
SSD zwischengespeichert sind, anstatt
von der regulären Platte gelesen werden zu müssen.
L2ARC kann ebenfalls die Deduplizierung
beschleunigen, da eine DDT, welche
nicht in den RAM passt, jedoch in den
L2ARC wesentlich schneller sein wird
als eine DDT, die von der Platte
gelesen werden muss. Die Häufigkeit, in der Daten zum
Cache-Gerät hinzugefügt werden, ist begrenzt, um zu
verhindern, dass eine SSD frühzeitig
durch zu viele Schreibvorgänge aufgebraucht ist. Bis
der Cache voll ist (also der erste Block verdrängt
wurde, um Platz zu schaffen), wird das Schreiben auf den
L2ARC begrenzt auf die Summe der
Schreibbegrenzung und das Bootlimit, sowie hinterher auf
das Schreiblimit. Ein paar sysctl(8)-Werte steuert
diese Limits. vfs.zfs.l2arc_write_max
steuert, wie viele Bytes in den Cache pro Sekunde
geschrieben werden, während vfs.zfs.l2arc_write_boost
zu diesem Limit während der „Turbo Warmup
Phase“ hinzuaddiert wird (Write Boost). |
ZIL | ZIL beschleunigt synchrone Transaktionen durch die Verwendung von Speichermedien wie SSDs, welche schneller sind als diejenigen, welche Teil des Speicherpools sind. Wenn eine Anwendung einen synchronen Schreibvorgang anfordert (eine Garantie, dass die Daten sicher auf den Platten gespeichert wurden anstatt nur zwischengespeichert zu sein, um später geschrieben zu werden), werden die Daten auf den schnelleren ZIL-Speicher geschrieben und dann später auf die regulären Festplatten. Dies reduziert die Latenz sehr und verbessert die Geschwindigkeit. Nur synchrone Vorgänge wie die von Datenbanken werden durch den Einsatz eines ZIL profitieren. Reguläre, asynchrone Schreibvorgänge wie das Kopieren von Dateien wird den ZIL überhaupt nicht verwenden. |
Copy-On-Write | Im Gegensatz zu traditionellen Dateisystemen werden beim Überschreiben von Daten bei ZFS die neuen Daten an einen anderen Block geschrieben, anstatt die alten Daten an der gleichen Stelle zu überschreiben. Nur wenn dieser Schreibvorgang beendet wurde, werden die Metadaten aktualisiert, um auf die neue Position zu verweisen. Im Falle eines kurzen Schreibvorgangs (ein Systemabsturz oder Spannungsverlust während eine Datei geschrieben wird) sind die gesamten Inhalte der Originaldatei noch vorhanden und der unvollständige Schreibvorgang wird verworfen. Das bedeutet auch, dass ZFS nach einem unvorhergesehenen Ausfall keinen fsck(8) benötigt. |
Dataset | Dataset ist der generische
Begriff für ein ZFS-Dateisystem,
Volume, Schnappschüsse oder Klone. Jedes Dataset
besitzt einen eindeutigen Namen in der Form
poolname/path@snapshot Die
Wurzel des Pools ist technisch gesehen auch ein Dataset.
Kind-Datasets werden hierarchisch wie Verzeichnisse
benannt. Beispielsweise ist
mypool/home das
Heimatdataset, ein Kind von
mypool und erbt die
Eigenschaften von diesem. Dies kann sogar noch
erweitert werden durch das Erstellen von
mypool/home/user . Dieses
Enkelkind-Dataset wird alle Eigenschaften von den Eltern
und Großeltern erben. Eigenschaften auf einem Kind
können die geerbten Standardwerte der Eltern und
Großeltern ändern und überschreiben. Die Verwaltung
von Datasets und dessen Kindern lässt sich
delegieren. |
Dateisystem | Ein ZFS-Dataset wird meistens als ein Dateisystem verwendet. Wie jedes andere Dateisystem kann auch ein ZFS-Dateisystem irgendwo in der Verzeichnishierarchie eingehängt werden und enthält seine eigenen Dateien und Verzeichnisse mit Berechtigungen, Flags und anderen Metadaten. |
Volume | Zusätzlich zu regulären Dateisystem-Datasets, kann ZFS auch Volumes erstellen, die Blockgeräte sind. Volumes besitzen viele der gleichen Eigenschaften, inklusive copy-on-write, Schnappschüsse, Klone und Prüfsummen. Volumes sind nützlich, um andere Dateisystemformate auf ZFS aufzusetzen, so wie UFS Virtualisierung, oder das Exportieren von iSCSI-Abschnitten. |
Snapshot (Schnappschuss) | Das copy-on-write
(COW)-Entwicklung von
ZFS erlaubt das Erstellen von beinahe
sofortigen, konsistenten Schnappschüssen mit beliebigen
Namen. Nachdem ein Schnappschuss von einem Dataset
angelegt oder ein rekursiver Schnappschuss eines
Elterndatasets, welcher alle Kinddatasets enthält,
erstellt wurde, werden neue Daten auf neue Blöcke
geschrieben, jedoch die alten Blöcke nicht wieder als
freier Speicher zurückgewonnen. Der Schnappschuss
enthält die Originalversion des Dateisystems und das
aktive Dateisystem besitzt alle Änderungen, die seit dem
Schnappschuss erstellt wurden. Kein zusätzlicher Platz
wird benötigt. Werden neue Daten auf das aktive
Dateisystem geschrieben, werden neue Blöcke allokiert,
um diese Daten zu speichern. Die scheinbare Größe des
Schnappschusses wird wachsen, da die Blöcke nicht mehr
länger im aktiven Dateisystem, sondern nur noch im
Schnappschuss Verwendung finden. Diese Schnappschüsse
können nur lesend eingehängt werden, um vorherige
Versionen von Dateien wiederherzustellen. Ein rollback eines
aktiven Dateisystems auf einen bestimmten Schnappschuss
ist ebenfalls möglich, was alle Änderungen, die seit dem
Anlegen des Schnappschusses vorgenommen wurden, wieder
Rückgängig macht. Jeder Block im Pool besitzt einen
Referenzzähler, der verfolgt, wieviele Schnappschüsse,
Klone, Datasets oder Volumes diesen Block nutzen. Wenn
Dateien und Schnappschüsse gelöscht werden, verringert
dies auch den Referenzzähler. Wenn ein Block nicht mehr
länger referenziert wird, kann er als freier Speicher
wieder genutzt werden. Schnappschüsse können auch mit
hold markiert
werden. Wenn versucht wird, einen solchen Schnappschuss
zu zerstören, wird stattdessen ein
EBUSY -Fehler ausgegeben. Jeder
Schnappschuss kann mehrere holds besitzen, jeder mit
einem eindeutigen Namen. Das Kommando release entfernt
diese, damit der Schnappschuss gelöscht werden kann.
Schnappschüsse lassen sich auf Volumes ebenfalls
anlegen, allerdings können diese nur geklont oder
zurückgerollt werden, nicht jedoch unabhängig
eingehängt. |
Clone (Klone) | Schnappschüsse können auch geklont werden. Ein Klon stellt eine veränderbare Version eines Schnappschusses dar, was es ermöglicht, das Dateisystem als neues Dataset aufzuspalten. Genau wie bei einem Schnappschuss verbraucht ein Klon keinen zusätzlichen Platz. Wenn neue Daten auf einen Klon geschrieben und neue Blöcke allokiert werden, wächst auch die Größe des Klons. Wenn Blöcke im geklonten Dateisystem oder Volume überschrieben werden, verringert sich auch der Referenzzähler im vorherigen Block. Der Schnappschuss, auf dem der Klon basiert kann nicht gelöscht werden, weil der Klon darauf eine Abhängigkeit besitzt. Der Schnappschuss stellt den Elternteil dar und der Klon das Kind. Klone lassen sich promoted (befördern), was die Abhängigkeit auflöst und den Klon zum Elternteil macht und den vorherigen Elternteil das Kind. Diese Operation benötigt keinen zusätzlichen Plattenplatz. Da die Menge an verwendetem Speicher vom Elternteil und dem Kind vertauscht wird, betrifft dies eventuell vorhandene Quotas und Reservierungen. |
Checksum (Prüfsumme) | Jeder Block, der allokiert wird erhält auch eine
Prüfsumme. Der verwendete Prüfsummenalgorithmus ist
eine Eigenschaft jedes Datasets, siehe dazu set .
Die Prüfsumme jedes Blocks wird transparent validiert
wenn er gelesen wird, was es ZFS
ermöglicht, stille Verfälschung zu entdecken. Wenn die
gelesenen Daten nicht mit der erwarteten Prüfsumme
übereinstimmen, wird ZFS versuchen,
die Daten aus jeglicher verfügbarer Redundanz (wie
Spiegel oder RAID-Z) zu
rekonstruieren. Eine Überprüfung aller Prüfsummen kann
durch das Kommando scrub
ausgelöst werden.
Prüfsummenalgorithmen sind:
fletcher -Algorithmen sind
schneller, aber dafür ist sha256 ein
starker kryptographischer Hash und besitzt eine viel
niedrigere Chance auf Kollisionen zu stoßen mit dem
Nachteil geringerer Geschwindigkeit. Prüfsummen können
deaktiviert werden, dies wird aber nicht
empfohlen. |
Compression | Jedes Dataset besitzt eine compression-Eigenschaft,
die standardmäßig ausgeschaltet ist. Diese Eigenschaft
kann auf eine Reihe von Kompressionsalgorithmen
eingestellt werden. Dadurch werden alle neuen Daten,
die auf das Dataset geschrieben werden, komprimiert.
Neben einer Reduzierung von verbrauchtem Speicher wird
oft der Lese- und Schreibdurchsatz erhöht, weil weniger
Blöcke gelesen oder geschrieben werden müssen.
|
Copies | Wenn die Eigenschaft copies auf
einen Wert grösser als 1 gesetzt wird, weist das
ZFS an, mehrere Kopien eines Blocks
im Dateisystem
oder
Volume anzulegen.
Diese Eigenschaft auf einem wichtigen Dataset
einzustellen sorgt für zusätzliche Redundanz, aus der
ein Block wiederhergestellt werden kann, der nicht mehr
mit seiner Prüfsumme übereinstimmt. In Pools ohne
Redundanz ist die copies-Eigenschaft die einzige Form
von Redundanz. Die Eigenschaft kann einen einzelnen
schlechten Sektor oder andere Formen von kleineren
Verfälschungen wiederherstellen, schützt jedoch nicht
den Pool vom Verlust einer gesamten Platte. |
Deduplizierung | Prüfsummen ermöglichen es, Duplikate von Blöcken zu
erkennen, wenn diese geschrieben werden. Mit
Deduplizierung erhöht sich der Referenzzähler eines
existierenden, identischen Blocks, was Speicherplatz
einspart. Um Blockduplikate zu erkennen, wird im
Speicher eine Deduplizierungstabelle
(DDT) geführt. Die Tabelle enthält
eine Liste von eindeutigen Prüfsummen, die Position
dieser Blöcke und einen Referenzzähler. Werden neue
Daten geschrieben, wird die Prüfsumme berechnet und mit
der Liste verglichen. Wird eine Übereinstimmung
gefunden, wird der existierende Block verwendet. Der
SHA256-Prüfsummenalgorithmus wird mit
Deduplizierung benutzt, um einen sicheren
kryptographischen Hash zu bieten. Deduplizierung lässt
sich konfigurieren. Wenn dedup auf
on steht, wird angenommen, dass eine
übereinstimmende Prüfsumme bedeutet, dass die Daten
identisch sind. Steht dedup auf
verify , werden die Daten in den
beiden Blöcken Byte für Byte geprüft, um
sicherzustellen, dass diese wirklich identisch sind.
Wenn die Daten nicht identisch sind, wird die Kollision
im Hash vermerkt und die beiden Blöcke separat
gespeichert. Da die DDT den Hash
jedes einzigartigen Blocks speichern muss, benötigt sie
eine große Menge an Speicher. Eine generelle
Faustregel besagt, dass 5-6 GB RAM pro 1 TB
deduplizierter Daten benötigt werden. In Situationen,
in denen es nicht praktikabel ist, genug
RAM vorzuhalten, um die gesamte
DDT im Speicher zu belassen, wird die
Geschwindigkeit stark darunter leiden, da die
DDT von der Platte gelesen werden
muss, bevor jeder neue Block geschrieben wird.
Deduplizierung kann den L2ARC nutzen,
um die DDT zu speichern, was einen
guten Mittelweg zwischen schnellem Systemspeicher und
langsameren Platten darstellt. Bedenken Sie, dass durch
die Verwendung von Komprimierung meistens genauso große
Platzersparnis möglich ist, ohne den zusätzlichen
Hauptspeicherplatzbedarf. |
Scrub (Bereinigung) | Anstatt einer Konsistenzprüfung wie fsck(8)
verwendet ZFS
scrub . scrub
liest alle Datenblöcke, die auf dem Pool gespeichert
sind und prüft deren Prüfsumme gegen die als richtig
in den Metadaten gespeicherte Prüfsumme. Eine
periodische Prüfung aller im Pool gespeicherten Daten
versichert, dass verfälschte Blöcke rekonstruiert werden
können, bevor dies nötig ist. Ein Scrub wird nicht nach
einem unsauberen Herunterfahren benötigt, wird jedoch
einmal alle drei Monate angeraten. Die Prüfsumme von
jedem Block wird verifiziert, wenn Blöcke während des
normalen Betriebs gelesen werden, jedoch stellt ein
Scrub sicher, dass sogar weniger häufig verwendete
Blöcke auf stille Verfälschungen hin untersucht werden.
Datenintegrität wird dadurch erhöht, besonders wenn es
sich um Archivspeichersituationen handelt. Die relative
Priorität des scrub lässt sich mit
vfs.zfs.scrub_delay
anpassen, um zu verhindern, dass der scrub die
Geschwindigkeit von anderen Anfragen auf dem Pool
beeinträchtigt. |
Dataset Quotas | ZFS bietet sehr schnelle und
akkurate Dataset-, Benutzer- und
Gruppenspeicherplatzbuchhaltung, zusätzlich zu Quotas
und Speicherplatzreservierungen. Dies gibt dem
Administrator feingranulare Kontrolle darüber, wie
Speicherplatz allokiert und die Reservierung für
kritische Dateisysteme vorgenommen wird
ZFS unterstützt verschiedene Arten von Quotas: die Dataset-Quota, die Referenzquota (refquota), die Benutzerquota und die Gruppenquota sind verfügbar. Quotas beschränken die Menge an Speicherplatz, welche ein Dataset, seine Kinder, einschließlich Schnappschüsse des Datasets, deren Kinder und die Schnappschüsse von diesen Datasets, verbrauchen können. Anmerkung:Quotas können nicht auf Volumes gesetzt werden,
da die Eigenschaft |
Referenzquota | Ein Referenzquota beschränkt die Menge an Speicherplatz, die ein Dataset verbrauchen kann durch das Erzwingen einer harten Grenze. Jedoch beinhaltet diese harte Grenze nur Speicherplatz, die das Dataset referenziert und beinhaltet nicht den Speicher, der von Kindern, wie Dateisystemen oder Schnappschüssen, verbraucht wird. |
Benutzerquota | Benutzerquotas sind hilfreich, um die Menge an Speicherplatz, die ein bestimmter Benutzer verbrauchen kann, einzuschränken. |
Gruppenquota | Die Gruppenquota beschränkt die Menge an Speicherplatz, die eine bestimmte Gruppe verbrauchen darf. |
Dataset-Reservierung | Die Eigenschaft reservation
ermöglicht es, ein Minimum an Speicherplatz für ein
bestimmtes Dataset und dessen Kinder zu garantieren.
Wenn eine Reservierung von 10 GB auf
storage/home/bob gesetzt ist und
ein anderes Dataset versucht, allen freien Speicherplatz
zu verwenden, bleiben zumindest noch 10 GB an
Speicher reserviert. Wenn von
storage/home/bob ein Schnappschuss
angelegt wird, wird dieser von der Reservierung
abgezogen und zählt damit dagegen.
Die Eigenschaft refreservation
funktioniert auf ähnliche Weise, jedoch
exkludiert diese Kinder wie
Schnappschüsse.
Reservierungen jeder Art sind in vielen Situationen nützlich, so wie bei der Planung und dem Testen der richtigen Speicherplatzallokation in einem neuen System oder durch die Zusicherung, dass genug Speicherplatz auf Dateisystemen für Audio-Logs oder Systemwiederherstellungsprozeduren und Dateien verfügbar ist. |
Referenzreservierung | Die Eigenschaft refreservation
ermöglicht es, ein Minimum an Speicherplatz für die
Verwendung eines bestimmten Datasets zu garantieren,
exklusiv dessen Kinder. Das
bedeutet, dass wenn eine 10 GB-Reservierung auf
storage/home/bob vorhanden ist und
ein anderes Dataset versucht, alle freien Speicherplatz
aufzubrauchen, sind zumindest noch
10 GB Speicher reserviert. Im Gegensatz zu einer
regulären Reservierung wird
der Speicher von Schnappschüssen und Kinddataset nicht
gegen die Reservierung gezählt. Beispielsweise, wenn
ein Schnappschuss von
storage/home/bob angelegt wird,
muss genug Plattenplatz außerhalb der Menge an
refreservation vorhanden sein, damit
die Operation erfolgreich durchgeführt wird. Kinder des
Hauptdatasets werden nicht in die Menge an
refreservation gezählt und dringen
auf diese Weise auch nicht in den gesetzten Speicher
ein. |
Resilver | Wenn eine Platte ausfällt und ersetzt wird, muss die neue Platte mit den Daten gefüllt werden, die verloren gegangen sind. Der Prozess der Verwendung der Paritätsinformationen, welche über die übrigen Platten verteilt sind, um die fehlenden Daten zu berechnen und auf die neue Platte zu übertragen, wird resilvering genannt. |
Online | Ein Pool oder vdev im Zustand
Online besitzt alle verbundenen
Mitgliedsgeräte und ist voll funktionsfähig.
Individuelle Geräte im Zustand
Online funktionieren normal. |
Offline | Individuelle Geräte lassen sich vom Administrator
in den Zustand Offline versetzen,
wenn es ausreichend Redundanz gibt, um zu verhindern,
dass der Pool oder das vdev in den Zustand
Faulted versetzt
wird. Ein Administrator kann eine Platte vor einem
Austausch offline nehmen oder um es leichter zu machen,
diese zu identifizieren. |
Degraded | Ein Pool oder vdev im Zustand
Degraded hat eine oder mehrere
Platten, welche getrennt wurden oder ausgefallen sind.
Der Pool kann immer noch verwendet werden, doch wenn
noch weitere Geräte ausfallen, kann der Pool nicht
wiederhergestellt werden. Die fehlenden Geräte
anzuschließen oder die defekten Platten zu ersetzen
wird den Pool wieder in den Zustand
Online versetzen,
nachdem die angeschlossenen oder neuen Geräte den
Resilver-Prozess
abgeschlossen haben. |
Faulted | Ein Pool oder vdev im Zustand
Faulted funktioniert nicht länger.
Die Daten darauf sind nicht mehr länger verfügbar. Ein
Pool oder vdev geht in den Zustand
Faulted über, wenn die Anzahl der
fehlenden oder defekten Geräte die Redundanzstufe im
vdev überschreiten. Wenn fehlende Geräte angeschlossen
werden, geht der Pool wieder in den Zustand Online. Wenn es nicht
genügend Redundanz gibt, um die Anzahl an defekten
Platten zu kompensieren, sind die Inhalte des Pools
verloren und müssen von der Sicherung wiederhergestellt
werden. |
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an
<de-bsd-translators@de.FreeBSD.org>.