ubuntuusers.de

Wiki

ZFS on Linux

Hinweis: Dies ist ein statischer Snapshot unseres Wikis vom März 25, 2017 und kann daher nicht bearbeitet werden. Der aktuelle Artikel ist unter wiki.ubuntuusers.de zu finden.

Wiki

Mitmachen

Konfiguration

ZFS on Linux

Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:

Artikel für fortgeschrittene Anwender

Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.

Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:

  1. Aktivieren eines PPAs

  2. Installation von Programmen

  3. Ein Terminal öffnen

Inhaltsverzeichnis
  1. Grundlagen
  2. Voraussetzungen
  3. Installation
  4. Nutzung
  5. Warnungen
  6. Beispiele
  7. Problembehebung
  8. Links

./zol_logo.png ZFS (ursprünglich Zettabyte File System) wird oft als Dateisystem angesehen, was im Grunde genommen ein Missverständnis darstellt. ZFS kann ein Dateisystem sein, aber beherrscht auch noch einiges mehr. Es vereint die Funktionalität eines Logical Volume Managers und eines Software-RAID mit einem Copy-on-Write-Dateisystem (COW). Das heißt, dass es (aufgrund seiner Kenntnisse der Festplattenbelegung) effizienter als jedes Hardware-RAID arbeitet, Daten-Integrität per Transaktionen ähnlich wie bei relationalen Datenbanken sichert und im Falle von Daten-Redundanz (Mehrfachspeicherung) sogar selbständig Daten repariert.

ZFS ist ein 128-bit-Dateisystem, das die Adressierung von 1.000.000.000.000.000.000.000 (1021) Bytes erlaubt (zum Vergleich siehe Binärpräfix). Es ist wahrscheinlich das fortschrittlichste Dateisystem, das es derzeit gibt. Abschließend noch ein Zitat von Jeff Bonwick, dem Chefentwickler von ZFS:

"Ein 128-bit-Dateisystem zu füllen, würde die quantenmechanische Grenze irdischer Datenspeicherung übersteigen. Man könnte einen 128-bit-Speicher-Pool nicht füllen, ohne die Ozeane zu verdampfen."

Grundlagen

Konzepte

ZFS verfolgt seit seinem Entwurf äußerst ehrgeizige Ziele. Als Beispiele seien genannt:

  • Integrität und Sicherheit der Daten gegenüber Datenverlusten standen immer an erster Stelle.

  • Ein Dateisystem für beliebig viele Daten. Selbst überirdische Größenordnungen wären ohne Weiteres möglich, sofern die Hardware mitspielt.

  • Bedienbarkeit, Administration und Benutzerschnittstelle sollen einfach sein. ZFS kommt mit nur zwei Befehlen aus: zpool für Festplatten-orientiertes Management und zfs für den Rest (also was man früher womöglich Partitionieren genannt haben würde).

  • Einfachstes Konzept: Man gebe der Verwaltung Plattenplatz in Form von Festplatten, Partitionen oder Dateien – gut zum Kennenlernen/Testen – und teile ZFS mit, wie es damit umgehen soll: als Bereiche für Datenspiegelung/Redundanz/RAID, für Transaktionslogs und/oder als Zwischenspeicher (Cache; bevorzugt auf schnellen Medien wie SSDs) usw. Dann wird alles als sogenannter Speicherpool zusammengefasst. Daraus kann man dann beliebige Teile belegen/reservieren, um darauf Dateien zu speichern oder auch ganze "Volumes" bereit stellen zu lassen. Ergebnis: Man muss nicht mehr wissen, wo genau der Speicherplatz dafür physikalisch herkommt. Die Eigenschaften jedes Dateisystems lassen sich auch später noch dynamisch verändern, ihre Größe könnte sogar annähernd den gesamten Pool einnehmen.

  • Wer – etwa für viele Benutzer – viele Dateisysteme und Volumes zu verwalten hat, wird es zu schätzen wissen, dass sie hierarchisch strukturiert werden können und ihre Eigenschaften vererbbar sind. So kann man z.B. für Nutzergruppen, Datenarten oder -verwendungszwecke sinnvolle Voreinstellungen treffen, die über solche Dinge entscheiden wie Speicherplatzhöchstgrenzen (Quota), -mindestbedarf (Reservation), Kompression, Schreibschutz, Empfindlichkeit für Klein/Großbuchstaben bei Dateinamen und Cachingverhalten. Alle Möglichkeiten aufzuzählen würde den Rahmen dieses Artikels sprengen.

  • Ein weiterer Nutzen der COW-Arithmetik: Das Festhalten/Einfrieren von Zuständen des Dateisystems (Snapshots), die auch im laufenden System stabile Marken für Backups/Replikation schaffen, ist sehr einfach. Sie erlauben es, auf andere Zustände/Zeitpunkte eines Dateisystems zuzugreifen, als wären davon Kopien erstellt worden.

  • ZFS überwacht die Integrität der verwalteten Daten, erkennt also auftretende Fehler selbst. Liegen die Daten in redundanter Form vor, wird es beim Erkennen von Fehlern selbständig deren Reparatur auslösen. Deswegen hat es den Ruf, Datenschäden selbstständig zu erkennen und zu reparieren, die in den darunter liegenden Schichten entstehen können. Es wurde sogar eine Technologie entwickelt, die das Write-hole-Problem {en} bei RAID-5 umgeht und die RAID-Z genannt wird.

Geschichte

ZFS wurde seit 2001 ursprünglich für das Betriebssystem Solaris entwickelt. Ende 2005 wurde der ZFS-Code dann unter der CDDL-Lizenz frei gegeben. Einige Unix-Derivate übernahmen ihn und es entstand u.a. auch der Ableger "zfs-fuse" (siehe unten). Allerdings läuft FUSE (Filesystem in Userspace) weder so sicher noch so schnell wie die neueste Entwicklung ZFS on Linux {en} (im weiteren Verlauf als ZoL abgekürzt). An dieser wurde bis Anfang 2013 gearbeitet, um die Integration in den Linux-Kernel voranzutreiben. Aus lizenzrechtlichen Gründen ist letzteres leider gescheitert. Erlaubt ist aber das Einbinden eines selbst kompilierten Kernel-Moduls, was unter Ubuntu über ein PPA sehr einfach zu bewerkstelligen ist. Federführend bei der Entwicklung war/ist das Lawrence Livermore National Laboratory (LLNL) im Auftrag des amerikanischen Verteidigungsministeriums.

Grundlage der Portierung war ZFS-Version 28 (bei zfs-fuse noch Version 23). Damit ist die Kompatibilität mit Solaris 10, OpenSolaris, OpenIndiana und FreeBSD gegeben. Solaris 11 als Nachfolger von Solaris 10 verwendet dagegen Version 34 (Stand: April 2012). ZoL und OpenIndiana haben sich auf eine architektonische Veränderung verständigt, die es erlaubt, nur wirklich benötigte Funktionen einzuschalten, als "Feature-Flag-Version" bezeichnet wird und sich als Version 5000 ausgibt (siehe dazu auch den ZFS Versionsvergleich).

Anfang April 2013 hat ZoL offiziell das Entwicklungsstadium verlassen und wird nun auch für den Einsatz auf Produktivsystemen empfohlen. Heute entwickeln Oracle (als Bestandteil von Solaris) und OpenIndiana ZFS unabhängig voneinander weiter (siehe auch Der Stand von ZFS für Linux {de}, Pro-Linux.de, 09/2014).

zfs-fuse

Bevor ZoL Form angenommen hat, existierte mit zfs-fuse {en} (ZFS in Userspace) bereits ein Versuch, ZFS-Funktionalität für 32-Bit-Prozessoren unter Linux zur Verfügung zu stellen. Diese Variante ist in den offiziellen Paketquellen enthalten (es wird die ZFS-Version 23 angeboten). Allerdings hat es hier seit ZFS-Version 26 keine Wartung mehr gegeben. Für Interessierte existiert ein Quellpaket der letzten zfs-fuse-Version im RPM-Format zum Herunterladen: zfs-fuse-0.7.0.20121023-5.el6.src.rpm {dl}. Es scheint, dass das Projekt seine Arbeit eingestellt hat.

Fertigprodukte

Es gibt – insbesondere für den Bereich der Netzwerkspeicher (NAS) – auch für den privaten Anwender inzwischen einige Anbieter, die von ZFS Gebrauch machen: MyNAS {de}, FreeNAS (ab Version 8.x) und NAS4Free {en} (die beiden letzten verwenden FreeBSD als Basis).

Voraussetzungen

64-Bit-Prozessor, umfangreicher Hauptspeicher

Die Vorteile von ZFS kommen auf einem normalen Desktop-System womöglich nicht voll zur Geltung. Es werden beispielsweise 4 GiB oder mehr freier Arbeitsspeicher empfohlen (Faustregel: 1 GiB Arbeitsspeicher pro TiB Speicherplatz in den Pools). Bestimmte Funktionen (insbesondere Deduplizierung) erfordern noch mehr (ab 16 GiB). Erst der Einsatz im Server-Bereich und in Rechenzentren liefert sinnvolle Nutzungsmöglichkeiten zur effizienten Verwaltung sehr großer Datenmengen.

Verfügt man aber über angemessene Hardware (64-Bit-Prozessor, viel RAM, genügend Festplattenanschlüsse), dann macht sich die Erleichterung im Bereich Festplatten-Speichermanagement auch für den privaten Nutzer schnell bemerkbar. Empfehlenswert ist außerdem die Lektüre von Myths and Misunderstandings: ZFS {en}, die einige häufige Missverständnisse ausräumt.

Abhängigkeiten

Folgende Pakete sind zwingende Voraussetzung, damit die Fremdquelle eingebunden und das Kernelmodul kompiliert werden kann:

  • software-properties-common

  • linux-headers

  • dkms

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren: 

sudo apt-get install software-properties-common linux-headers dkms 

sudo aptitude install software-properties-common linux-headers dkms

Installation

ZoL war bis April 2016 kein offizieller Bestandteil von Ubuntu und damit auch nicht in den offiziellen Paketquellen enthalten. Stattdessen kann man bis einschließlich Ubuntu 15.10 die "Personal Package Archive" (PPAs) des Launchpad-Projekts zfs {en} nutzen oder den Quelltext selbst kompilieren (zu Letzterem siehe Links). Für Erläuterungen zur Installation sei auch auf die sehr gute FAQ {en} des ZoL-Projekts verwiesen.

Erst ab Ubuntu 16.04 sind die entsprechenden ZFS-Komponenten in den offiziellen Paketquellen enthalten (siehe auch ZFS {en}):

  • zfsutils-linux

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren: 

sudo apt-get install zfsutils-linux 

sudo aptitude install zfsutils-linux

PPA

Es gibt zwei "Personal Package Archive" (PPA) [1] für ZFS. Das "stable"-PPA ist für die reine Nutzung von ZFS ausreichend.

Hinweis:

Bitte niemals beide PPAs gleichzeitig aktivieren.

stable

Adresszeile zum Hinzufügen des PPAs:

  • ppa:zfs-native/stable

Hinweis!

Zusätzliche Fremdquellen können das System gefährden.

Ein PPA unterstützt nicht zwangsläufig alle Ubuntu-Versionen. Weitere Informationen sind der Wiki/Vorlagen/PPA/ppa.png PPA-Beschreibung des Eigentümers/Teams zfs-native zu entnehmen.

Damit Pakete aus dem PPA genutzt werden können, müssen die Paketquellen neu eingelesen werden.

Nach dem Aktualisieren der Paketquellen kann das folgende Paket installiert [2] werden:

  • ubuntu-zfs (ppa)

Wiki/Vorlagen/Installbutton/button.png mit apturl

Paketliste zum Kopieren: 

sudo apt-get install ubuntu-zfs 

sudo aptitude install ubuntu-zfs

Nun wird automatisch:

  1. der aktuelle Quellcode heruntergeladen und

  2. mit Hilfe von DKMS kompiliert (der Vorgang dauert ein wenig)

daily

Speziell für Entwickler gedacht war das PPA zfs-native/daily {en}. Die Installation erfolgt wie oben angegeben.

Nutzung

Dokumentation lesen

Über die Nutzung von ZFS mit seinen zahlreichen Möglichkeiten lassen sich ganze Bücher schreiben. Wer sich für die Materie interessiert, sei auf die sehr gute ZFS-Dokumentation verwiesen (siehe Links). Diese liegt allerdings durchgehend auf Englisch vor, Quellen auf Deutsch sind extrem selten. Grafische Konfigurationswerkzeuge sind ebenfalls nicht vorhanden.

Test

Es hat sich für Umsteiger bewährt, ZFS zunächst nur (große, idealerweise unfragmentierte) Dateien als Speichermedium anzubieten, um die Funktionalität kennen zu lernen, sie erforschen und erproben zu können. Siehe dazu auch das Beispiel. Wer möchte, kann ZFS stattdessen Partitionen anbieten.

Planung

Weiterhin hat es sich bewährt, einige Überlegungen vor der Datenmigration anzustellen, aus welcher der ZFS-Funktionen, insbesondere der Vererbung, im konkreten Anwendungsfall bestmöglicher Nutzen gewonnen werden kann.

Warnungen

Dies ist eine (ergänzte) Übersetzung der hervorragenden Seite "Best Practives and Caveats" (siehe Links).

Best Practices

Wie mit allen Empfehlungen haben manche großes Gewicht, während andere das möglicherweise nicht haben. Vielleicht wird es nicht einmal möglich sein, ihnen so strikt zu folgen, wie man das möchte. Doch sollte man sich ihrer bewusst sein. Es wird versucht, eine Begründung für jede Empfehlung zu geben. Sie haben keine besondere Reihenfolge. Die Ziele dieser "Best Practices" sind Speichereffizienz, Performance sowie maximale Datenintegrität.

  • Man erzeuge (reale) Pools immer mit den Optionen -o ashift=12 -d /dev/disk/by-id. Da neuere Festplatten mit Sektoren von 4096 Bytes arbeiten, werden mit ashift=12 die Sektoren des ZFS ebenfalls auf diese Größe festgelegt, um Performance-Einbußen zu vermeiden. Durch die Identifizierung der Platten mittels /dev/by-id wird erreicht, dass ZFS die Platten richtig ins System einbindet, unabhängig davon, an welchem Port sie angeschlossen sind, d.h. das System funktioniert weiter, auch wenn /dev/sda und /dev/sdb vertauscht wurden.

  • Wenn ein Pool zu über 80% gefüllt ist, wird er langsamer. In der Praxis wird empfohlen, diesen Wert nicht zu überschreiten. Man bedenke, dass in einem Pool, der zu 100% gefüllt ist, auch keine Löschung auf Dateiebene mehr möglich ist, weil kein Platz mehr für das "neue" leere Verzeichnis mehr vorhanden ist, der aber wegen der Copy-on-Write-Semantik benötigt wird.

  • Obwohl es möglich ist, alle Festplatten in einem einzigen Pool zusammen zu fassen, sollte man sich gut überlegen, ob das auch langfristig sinnvoll ist. Merke: Man kann einen Pool immer vergrößern. Das Verkleinern (Herausnehmen von Platten) geht nur in Ausnahmefällen, etwa wenn ein Festplattenspiegel (mirror) aus dem Pool entfernt werden soll. Die ZFS-Foren sind voll mit Einträgen von Anwendern, die das "vergessen hatten" oder "aus Versehen" den falschen Befehl, nämlich zpool add ... statt zpool attach ... verwendet haben, nur um dann zu erfahren, dass alle Daten wieder raus müssen, um den Pool korrekt strukturieren zu können. Siehe dazu auch das Beispiel Erweitern des Pools.

    Experten-Info:

    Mitunter kann es durchaus sinnvoll sein, mehrere Pools zu verwenden.

  • Benutze immer Kompression. Mit an Sicherheit grenzender Wahrscheinlichkeit gibt es keinen Grund, sie auszuschalten. Es kostet die CPU wenig, die Übertragungszeiten zur Platte ebensowenig, aber der Nutzeffekt ist erstaunlich.

  • ZFS Snapshots kann man gut regelmäßig und häufig erstellen. Sie sind problemlos erzeug- und nutzbar, und dieses Vorgehen ermöglicht es, eine Menge an Dateiversionen über längere Zeiträume zu bewahren. Es gibt ein Paket zfs-auto-snapshot, dessen Einsatz man erwägen sollte.

  • Snapshots sind kein Backup! Man benutze zfs send/recv, um die Snapshots auf einem externen Speicher zu sichern.

  • Wer NFS benutzt, der ziehe ZFS NFS exports den in NFS integrierten exports vor. Das stellt sicher, dass ein Dateisystem eingehängt und online ist, bevor NFS-Clients Daten senden.

  • NFS kernel exports und ZFS NFS exports möglichst nicht mischen. Dies ist schwierig zu administrieren und zu warten.

  • Für ZFS-/home/-Installationen lege man für jeden Benutzer ein eigenes ZFS-Dateisystem an (etwa /home/bob und /home/alice) und erwäge den Einsatz von Quotas (Beschränkung der Datenmenge pro Nutzer).

  • Wenn ZFS send/recv eingesetzt wird, bedenke man die Verwendung des -i Schalters (inkrementell). Das kann einen höchst erstaunlichen Zeitgewinn mit sich bringen.

  • zfs send ist einem rsync-basierten Ansatz überlegen, weil zfs send die Eigenschaften eines Dateisystems bewahren kann.

Achtung!

Die beiden folgenden Empfehlungen stammen nicht aus der Feder von Aaron Toponce, sondern aus der Diskussion (siehe Links), in der sich die Entwickler mit den frühen Anwendern ausgetauscht haben.

  • Booten von ZFS als Hauptdateisystem sollte auf GNU/Linux vorerst noch vermieden werden (Anm.: Viele Hinweise/Anleitungen im Netz zeigen, dass dies möglich ist. Dennoch...). Diese Konfiguration ist noch zu sehr experimentell, auch die GRUB-2-Unterstützung ist nur für bestimmte Konfigurationen vorhanden. Wer das versuchen will, sollte schon ein extrem versierter Linuxianer sein, am besten mit solidem Entwicklungswissen. Und er sollte in der Lage sein, die Rettung eines unbootbaren Systems mit grub-rescue, Initramfs-shell usw. zu bewerkstelligen. Denn es kann vorkommen, dass die gegenwärtigen Ubuntu-Systemaktualisierungen die Systeminstallation im ZFS-Hauptdateisystem beschädigen. Da heraus zu kommen ist nicht trivial! Wer hiermit Erfolg haben will, sollte sich gut informieren. Empfehlenswert ist zu diesem Zweck die Lektüre der bereits erwähnten Diskussion. Die Entwickler selbst gehen im Übrigen davon aus, dass es noch mehrere Jahre dauern wird, bis diese Architektur in GNU/Linux (Upstream) genügend gut integriert und unterstützt wird.

    Aber für Ordner wie /home/, /var/log/ und /var/cache/ kann man gut ZFS verwenden.

  • Niemals Deduplizierung einschalten! Zum einen verlangt Dedup sehr viel Hauptspeicher, mehr als sich in normalen privaten Computern befindet. Außerdem löst es – selbst, wenn nur ein Teil, z.B. ein Dateisystem, betroffen ist – eine bleibende Veränderung in der Funktionsweise des gesamten Pools aus, die nicht rückgängig gemacht werden kann, und die diesen hohen Ressourcenverbrauch permanent macht (überdies gibt es wohl nur wenige, die das schon getestet haben).

Warnungen/Vorbehalte

Der Sinn dieser Warnungen ist es keinesfalls, von der Verwendung von ZFS abzuschrecken. Als Systemadministrator, der einen ZFS-Speicher-Server plant, muss man sich dieser Dinge jedoch bewusst sein, damit es einen nicht kalt erwischt und man hinterher ohne Daten dasteht. Wer diese Warnungen nicht beherzigt, muss mit Datenverlust rechnen.

Achtung!

  • Ein zfs destroy kann eine Unterbrechung des Zugriffs auf andere Dateisysteme verursachen. Ein zfs destroy wird jede Datei in einem Dateisystem dieses Speicherpools berühren. Je größer das Dateisystem ist, umso länger wird dies dauern, und es wird alle möglichen IOPS der Platten nutzen, um dies auszuführen. Demzufolge wird, wenn das Zerstören des Dateisystems beispielsweise zwei Stunden dauert, potentiell zwei Stunden lang kein Zugriff auf die anderen Dateisysteme möglich sein (Anm.: Mit der Feature-Flag-Version wurde die Option async-destroy eingeführt, um dem zu begegnen).

  • Debian und Ubuntu starten den NFS-Daemon nicht ohne einen gültigen "export" in /etc/exports. Also muss man entweder einen Dummy-export anlegen oder das /etc/init.d/nfs-Skript anpassen.

  • Debian und Ubuntu nutzen einen parallelisierten Bootprozess. Dadurch ist die Reihenfolge, in der die Init-Skripte ausgeführt werden, nicht vorhersehbar. Dies führt zu Problemen beim Einbinden von ZFS-Dateisystemen zum Bootzeitpunkt. In Debian und Ubuntu muss die Datei /etc/init.d/.legacy-bootordering-Datei dahingehend geändert werden, dass /etc/init.d/zfs als erstes Skript in diesem Runlevel gestartet wird (Anm.: höchstwahrscheinlich nicht mehr aktuell, seit ZFS jetzt ein eigenes Paket mountall mitinstalliert).

  • Man sollte niemals einen Pool bauen, der Dateien/Volumes eines anderen Pools benutzt. Dies verursacht alle möglichen Schwierigkeiten (Anm.: Angeblich auch nicht mehr wahr... was die Idee aber nicht besser macht!).

  • Wenn man ZVOLs erzeugt, sollte deren Blocksize identisch oder ein Vielfaches der Blocksize sein, mit der man später formatieren will. Sonst kann dies zu Performance-Problemen führen.

  • Die in der Oracle-Dokumentation zu ZFS (siehe Links) angegebene Möglichkeit, Festplatten als "Hot Spare" zu konfigurieren, damit sie automatisch bei einem eingetretenen Festplattenausfall einspringen können, wird derzeit von ZoL (noch) nicht unterstützt. Manuell lässt sich die Funktionalität des Austauschens einer defekten Platte in einem Pool aber auslösen.

  • Es ist eine gute Idee, einen Maximalwert für den "Advanced Recovery Cache" (ARC) festzulegen, bevor das Kernelmodul zfs geladen wird. Wenn viele zfs-send-Befehle oder Snapshots ausgeführt werden, werden diese Daten im ARC zwischengespeichert. Ist kein Maximalwert festgelegt, wird das RAM nach und nach gefüllt, bis der Kernel "OOM Killer" ausführt, damit das System wieder reagieren kann.

    Abhilfe zum letzten Punkt: Beispielsweise führt der Eintrag 

    options zfs zfs_arc_max=2147483648

    in der Datei /etc/modprobe.d/zfs.conf zu einer Beschränkung auf 2 GiB RAM für ARC (Anm: Aufgrund von RAM-Fragmentierung kann dennoch Speicher bis zum Doppelten dieses Wertes benötigt werden!). Die Angabe erfolgt in Bytes, weitere mögliche Werte wären 17179869184 für 16 GiB, 8589934592 für 8 GiB, 4294967296 für 4 GiB oder 1073741824 für 1 GiB. Da der ARC beim Laden des Kernelmoduls gesetzt wird, wird anschließend ein Neustart empfohlen.

Trotz Maximalwert für ARC kann es zu Speicherproblemen kommen. Da ZFS aus seiner Ursprungsumgebung (Solaris) portiert wurde, mussten Anpassungen vorgenommen werden, die speziell Unterschiede in der Behandlung von virtuellem Speicher im Kernel betreffen. Die Unterschiede zwischen der "Solaris-Sicht" und der "Linux-Realität" verursachen u.a. unerwünschte Speicherverschwendung, für die es kein einfaches Heilmittel gibt.

Beispiele

Die folgenden Beispiele sind eigentlich ein einziges langes Beispiel, unterbrochen von Erläuterungen. Diesem Beispiel auf dem eigenen Rechner zu folgen, dürfte mindestens eine Zeitstunde in Anspruch nehmen. Und kann nicht annähernd die Lektüre der ZFS Dokumentation – ergänzt um eigene Tests – ersetzen (siehe Nutzung).

Hinweis:

Grundlage dieser Anleitung ist die Version 0.6.3 der Pakete zfs und spl (beide werden vom Metapaket ubuntu-zfs installiert).

Test mit Live-CD/-DVD

Es ist möglich, den Computer von einer Ubuntu-Live-CD zu starten und das Beispiel ausschließlich im Hauptspeicher ablaufen zu lassen, falls dieser über wenigstens 4 GiB RAM verfügt.

Experten-Info:

Empfohlen werden Ubuntu 12.04 oder 12.04.1 mit Kernel 3.2, die im historischen Archiv {dl} zu finden sind. Spätere Ausgaben wie 12.04.2, 12.04.3 usw. enthalten neuere Kernel, die für Probleme sorgen und auch nicht den gleichen Unterstützungszeitraum wie der Kernel 3.2 (bis April 2017) besitzen. Das Gleiche gilt prinzipiell auch für Ubuntu 14.04 mit dem Kernel 3.13.

Root-Shell

Da die folgenden Befehle (fast) alle Root-Rechte benötigen, wird zuerst eine Root-Shell geöffnet:

sudo -i

Bitte nicht vergessen, diese am Ende wieder zu schließen.

ZFS-Installation

apt-add-repository --yes ppa:zfs-native/stable
apt-get update
apt-get install --yes ubuntu-zfs

Da nun mehrere Kernel-Module kompiliert werden, dauert das eine Weile.

Erzeugen des Testpools

Erzeugung von Dateien (zum Aufbau des Testpools)

Dies ist nur als Demonstration gedacht, es handelt sich nicht um ein wirklichkeitsnahes Szenario. Um zeigen zu können, wie ein Pool erstellt wird (und eines der häufigsten Missverständnisse vorzuführen), werden als Erstes ein paar (sparse) Dateien als "Festplatten-Ersatz" erzeugt, aus denen der Pool später bestehen wird:

## der Speicherort dieser Festplatten-Simulationen
mkdir -p /mnt/free-space
cd /mnt/free-space/
## natürlich würden größere Dateien mehr Spielraum für Experimente geben (etwa -s 1G)
for disk in simulate.disk{1,2,3,4};do truncate -s 100M $disk;done
la -lhs 

insgesamt 0
0 -rw-r--r-- 1 root root 100M Nov 26 21:17 simulate.disk1
0 -rw-r--r-- 1 root root 100M Nov 26 21:17 simulate.disk2
0 -rw-r--r-- 1 root root 100M Nov 26 21:17 simulate.disk3
0 -rw-r--r-- 1 root root 100M Nov 26 21:17 simulate.disk4

Erzeugen des Pools aus Dateien

Nun wird bewusst ein Umweg eingeschlagen, um verschiedene Konzepte zu verdeutlichen (und einem weit verbreiteten Missverständnis vorzubeugen).

Hinweis:

Wer es eilig hat, kann diesen Umweg abkürzen, indem er direkt zum Abschnitt Abkürzung vor geht.

Aller Anfang ist klein:

## Bei diesen Experimenten ist `-o ashift=12` überflüssig. Würde es um reale Partitionen/Festplatten gehen, sähe das schon anders aus.
zpool create mypool /mnt/free-space/simulate.disk1
zpool status 

  pool: mypool
 state: ONLINE
  scan: none requested
config:

	NAME                              STATE     READ WRITE CKSUM
	mypool                            ONLINE       0     0     0
	  /mnt/free-space/simulate.disk1  ONLINE       0     0     0

errors: No known data errors
zpool list 

NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
mypool  95.5M   520K  95.0M     0%  1.00x  ONLINE  -

Erweitern des bestehenden Pools

Angenommen, dieser Pool soll erweitert werden (eine weitere "Platte" hinzugefügt werden), so gibt es verschiedene Möglichkeiten, dies zu tun. Man könnte einfach den Platz auf der nächsten Platte dem Pool hinzufügen wollen. Oder man könnte die zweite Platte als Medium für Redundanz, also als Spiegel der bereits bestehenden Festplatte hinzufügen. Das Ergebnis wäre sehr verschieden! Im ersten Fall vergrößert sich der Speicherplatz im Pool, im zweiten Fall vergrößert sich die Datensicherheit (und im Falle von realen Festplatten) im Allgemeinen auch die Lese-/Schreibgeschwindigkeit. Hier sei also die Absicht, den Pool sicherer zu machen und einen Spiegel hinzuzufügen.

Der prinzipielle Befehl würde zpool add ... lauten, aber ohne die Option -f (force) erlaubt zpool dies nicht, weil add und attach schon so häufig von Anwendern verwechselt worden ist:

Hinweis:

Der folgende Befehl macht nicht das, was in diesem Fall tatsächlich erforderlich wäre. Siehe auch Abkürzung. 

zpool add -f mypool /mnt/free-space/simulate.disk2

Mit dem Befehl: 

zpool status

kontrolliert man den Status:

  pool: mypool
 state: ONLINE
  scan: none requested
config:

	NAME                              STATE     READ WRITE CKSUM
	mypool                            ONLINE       0     0     0
	  /mnt/free-space/simulate.disk1  ONLINE       0     0     0
	  /mnt/free-space/simulate.disk2  ONLINE       0     0     0

errors: No known data errors
zpool list 

NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
mypool   191M   612K   190M     0%  1.00x  ONLINE  -

Unter Anderem kann man an der Vergrößerung des Wertes für SIZE erkennen, dass etwas Anderes als beabsichtigt passiert ist.

Fehlerhafte Pool-Konfiguration

Das war es nicht, was bezweckt worden ist. Was nun? Merke: Man kann den Speicherplatz eines Pool immer erweitern, aber es gibt keine Umkehrung dazu! Deshalb bieten sich hier die folgenden Möglichkeiten an:

  • Weil (in diesem Fall) noch keine Daten im Pool sind, wäre eine einfache Möglichkeit, den Pool zu beseitigen und von vorn zu beginnen, diesmal richtig. (Also zpool destroy mypool gefolgt von einem etwas komplexeren zpool create ...)

  • Man könnte alle Daten aus dem Pool extern sichern, dann den Pool zerstören und (korrekt) neu aufbauen, und schließlich die gesicherten Daten wieder zurückspielen. Verfügt man nicht über ausreichenden Ausweichspeicher, käme diese Alternative einer mittleren Katastrophe gleich.

  • Man könnte weitere Platten besorgen und nun beide Teile des Pools spiegeln.

Hier soll letzterer Weg eingeschlagen werden, weil er auch dann Erfolg haben würde, wenn sich bereits Daten im Pool befänden.

Reparatur

Dafür lohnt es sich, zu wissen, dass jeder Pool tatsächlich nicht direkt aus Geräten (also Platten, Partitionen oder Dateien) aufgebaut ist, sondern aus virtuellen Geräten ("vdevs"). Solche vdevs können ihrerseits einfache Geräte, Spiegel ("mirrors") oder RAID-Verbünde sein (verschiedene Möglichkeiten sind in der ZFS-Dokumentation beschrieben). Was hier entstehen soll, ist ein Pool mypool bestehend aus 2 vdevs, die ihrerseits jeweils aus 2 Geräten bestehen, die als Spiegel konfiguriert sein sollen.

Zur Erinnerung: Derzeit besteht der Pool aus 2 (unsichtbaren, namenlosen) vdevs mit jeweils einem Gerät darin. Nun werden die korrekten Befehle zur Erweiterung dieser vdevs ausgeführt:

zpool attach mypool /mnt/free-space/simulate.disk1 /mnt/free-space/simulate.disk3
zpool attach mypool /mnt/free-space/simulate.disk2 /mnt/free-space/simulate.disk4
zpool status 

  pool: mypool
 state: ONLINE
  scan: resilvered 15K in 0h0m with 0 errors on Tue Nov 26 21:17:43 2013
config:

NAME                                STATE     READ WRITE CKSUM
mypool                              ONLINE       0     0     0
  mirror-0                          ONLINE       0     0     0
    /mnt/free-space/simulate.disk1  ONLINE       0     0     0
    /mnt/free-space/simulate.disk3  ONLINE       0     0     0
  mirror-1                          ONLINE       0     0     0
    /mnt/free-space/simulate.disk2  ONLINE       0     0     0
    /mnt/free-space/simulate.disk4  ONLINE       0     0     0

errors: No known data errors

Man beachte, dass die vdevs hier mirror-0 und mirror-1 heißen und jeweils redundant den Speicherplatz eines Gerätes bereitstellen. Deshalb hat sich der benutzbare Speicher durch diesen letzten Schritt nicht weiter vergrößert.

zpool list 

NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
mypool   191M   711K   190M     0%  1.00x  ONLINE  -

Abkürzung

Dieselbe Konfiguration kann (und sollte!) idealerweise direkt mittels des Befehls:

zpool create mypool mirror /mnt/free-space/simulate.disk{1,3} mirror /mnt/free-space/simulate.disk{2,4}

erzeugt werden.

Anlegen von Dateisystemen

Es gibt Einstellungen, die sich auf den gesamten Pool beziehen (wie failmode, ashift, cachefile, ...). Davon können manche nur zum Zeitpunkt der Erzeugung gesetzt werden (z.B. ashift). Und es gibt Einstellungen, die sich auf die "Teile" (meistens Dateisysteme) beziehen, die in einem Pool bereitgestellt werden. Dabei handelt es sich um eine verzeichnisbaum-artig organisierte Hierarchie von Dateisystemen, in der Einstellungen vom "parent"-Knoten standardmäßig an die "child"-Knoten vererbt werden. Somit ist es (auch später noch) einfach, Dateisysteme, die in einem Sub-Tree zusammengefasst wurden, auf einen Schlag die gleichen Eigenschaften zuzuweisen (deswegen macht es Sinn, die Organisation dieser Dateisysteme vorauszuplanen).

Ohne dass eine Aktion dafür erforderlich gewesen wäre, wurde bereits ein Dateisystem (Die Wurzel) von ZFS erzeugt, dessen Eigenschaften auf die folgenden übertragen werden. Nun ist es zwar jederzeit möglich, die Einstellung compression zu verändern, aber sie beschreibt nur, auf welche Weise zukünftig Daten abgelegt werden sollen. Bereits gespeicherte Daten werden nicht neu geschrieben oder konvertiert. Darum ist es eine gute Idee, diese Einstellung jetzt zu treffen:

## Dateisystem-bezogene Operationen werden mit dem zfs-Befehl durchgeführt
zfs set compression=lz4 mypool

Darüber hinaus ist es nicht ratsam, Dateien in diesem Wurzel-Dateisystem anzulegen. Man bewahrt sich viel mehr Flexibilität, wenn man dieses eine leer lässt. In diesem Beispiel wird deswegen ein Dateisystem erzeugt, in dem tatsächlich auch einmal etwas gespeichert werden wird:

zfs create mypool/testarea 
cd /mypool/testarea

Man beachte, dass es nicht erforderlich war, dieses neue Datesystem einzuhängen. Das hat ZFS bereits erledigt. Und würde es an einer anderen Stelle im Verzeichnisbaum benötigt, so genügte die Veränderung der Einstellung mountpoint eben dieses Dateisystems.

Ebenso beachtenswert: Es wurde keine Größe für das Dateisystem angegeben. Dieses könnte geschehen, muss es aber nicht, weil sie auch im laufenen Betrieb noch dynamisch verändert werden kann. Ohne Größenangabe kann jedes Dateisystem den verbliebenen freien Platz in Anspruch nehmen.

ZFS Snapshots

Snapshots sind schreibgeschützte Kopien eines Dateisystems (oder Volumes). Sie zu erzeugen geschieht nahezu augenblicklich. Sie belegen (zunächst) kaum eigenen Speicherplatz. Erst, wenn sich der Inhalt des Dateisystems ändert, benötigen sie Speicherplatz, indem sie weiterhin auf ehemalige Dateizustände verweisen, die sich im aktuellen Dateisystem bereits verändert haben. Dadurch verhindern Snapshots, dass der ihnen zugeordnete Speicherplatz freigegeben wird. Sie reduzieren dabei den dem Dateisystem zugeordneten freien Platz. Snapshots können betrachtet oder geklont werden (dadurch verhalten sie sich dann wie ein änderbares Dateisystem), man kann sie verwerfen, oder auch als Wiederherstellungspunkt verwenden. Es gibt noch weitere Operationen mit Snapshots.

Da es aber nicht Sinn und Zweck dieses Artikels ist, alle Möglichkeiten von ZFS zu erklären, werden nun einige Beispiele folgen. Erst werden mehrere Zustände des Dateisystems erzeugt, dann wird davon einer geclont, zum Schluss werden andere Zustände nur betrachtet. Zunächst werden einige Dateien im Dateisystem /mypool/testarea erzeugt:

cp -R /var/log .
## Filter, um nur interessante Größenangaben anzuzeigen
zfs get all mypool/testarea | awk '$3 ~ /[GEKMx]$/' 

NAME             PROPERTY              VALUE                  SOURCE
mypool/testarea  used                  236K                   -
mypool/testarea  available             159M                   -
mypool/testarea  referenced            236K                   -
mypool/testarea  compressratio         5.68x                  -
mypool/testarea  recordsize            128K                   default
mypool/testarea  usedbydataset         236K                   -
mypool/testarea  refcompressratio      5.68x                  -
mypool/testarea  written               236K                   -

Der hohe Kompressionsfaktor in diesem Beispiel hängt von den vorhandenen Daten ab.

zfs snap mypool/testarea@varlog-importiert
for i in `seq 1 5`;do echo Dies ist Datei "file$i.txt" > file$i.txt;done
ll 

drwxr-xr-x  3 root root  8 Nov 26 21:18 ./
drwxr-xr-x  3 root root  3 Nov 26 21:18 ../
-rw-r--r--  1 root root 25 Nov 26 21:18 file1.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file2.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file3.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file4.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file5.txt
drwxr-xr-x 15 root root 39 Nov 26 21:18 log/

Nun noch ein weiterer Snapshot, gefolgt von Änderung, Snapshot, Löschung (einzelner Dateien):

zfs snap mypool/testarea@file1-5.txt-erzeugt
echo "Dies ist Datei drei (nach einer Änderung)" >> file3.txt
zfs snap mypool/testarea@file3.txt-geaendert
rm -v file{2,5}* 

»file2.txt“ wurde entfernt
»file5.txt“ wurde entfernt

Rollback

Zeige Verzeichnis, gehe auf den letzten Snapshot zurück und zeige erneut:

ll
zfs rollback mypool/testarea@file3.txt-geaendert
ll 

insgesamt 9
drwxr-xr-x  3 root root  6 Nov 26 21:18 ./
drwxr-xr-x  3 root root  3 Nov 26 21:18 ../
-rw-r--r--  1 root root 25 Nov 26 21:18 file1.txt
-rw-r--r--  1 root root 68 Nov 26 21:18 file3.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file4.txt
drwxr-xr-x 15 root root 39 Nov 26 21:18 log/

insgesamt 11
drwxr-xr-x  3 root root  8 Nov 26 21:18 ./
drwxr-xr-x  3 root root  3 Nov 26 21:18 ../
-rw-r--r--  1 root root 25 Nov 26 21:18 file1.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file2.txt
-rw-r--r--  1 root root 68 Nov 26 21:18 file3.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file4.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file5.txt
drwxr-xr-x 15 root root 39 Nov 26 21:18 log/

Da sind die Dateien wieder.

Clone

Nun werden noch mehr Dateien erzeugt und im Anschluss daran ein Clone (beschreibbare Kopie eines früheren Zustandes) erzeugt:

for i in `seq 6 8`;do echo Dies ist Datei "file$i.txt" > file$i.txt;done
zfs list -t snap
ll 

NAME                                  USED  AVAIL  REFER  MOUNTPOINT
mypool/testarea@varlog-importiert      26K      -   394K  -
mypool/testarea@file1-5.txt-erzeugt  18.5K      -   396K  -
mypool/testarea@file3.txt-geaendert     1K      -   396K  -

insgesamt 12
drwxr-xr-x  3 root root  8 Nov 26 21:18 ./
drwxr-xr-x  3 root root  3 Nov 26 21:18 ../
-rw-r--r--  1 root root 25 Nov 26 21:18 file1.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file2.txt
-rw-r--r--  1 root root 68 Nov 26 21:18 file3.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file4.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file5.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file6.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file7.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file8.txt
drwxr-xr-x 15 root root 39 Nov 26 21:18 log/
zfs clone mypool/testarea@file1-5.txt-erzeugt mypool/clonedemo
echo "Diese Dateien sind beschreibbar" > /mypool/clonedemo/file3.txt
ll /mypool/clonedemo/ 

insgesamt 11
drwxr-xr-x  3 root root  8 Nov 26 21:18 ./
drwxr-xr-x  3 root root  3 Nov 26 21:18 ../
-rw-r--r--  1 root root 25 Nov 26 21:18 file1.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file2.txt
-rw-r--r--  1 root root 32 Nov 26 21:18 file3.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file4.txt
-rw-r--r--  1 root root 25 Nov 26 21:18 file5.txt
drwxr-xr-x 15 root root 39 Nov 26 21:18 log/
cat file3.txt;echo;cat /mypool/clonedemo/file3.txt 

Dies ist Datei file3.txt
Dies ist Datei drei (nach einer Änderung)

Diese Dateien sind beschreibbar

Zustand alter Snapshots betrachten

In Gegensatz zur Möglichkeit, einen Clone anzulegen (der ja eine änderbare Kopie eines Snapshots bereit stellt), gibt es eine einfachere Möglichkeit, Snapshots schreibgeschützt einzuhängen. Das macht ZFS automatisch, wenn auf das .zfs/snapshot-Verzeichnis im betroffenen Dateisystem zugegriffen wird. Das ist auch dann möglich, wenn das .zfs-Verzeichnis nicht durch die Einstellung zfs set snapdir=visible <Dateisystem> ausdrücklich zugänglich gemacht wurde.

Hinweis:

Diese den Snapshots zugeordneten Unterverzeichnisse werden auch dynamisch wieder ausgehängt! 

for fs in /mypool/*;do find $fs -name "file3.txt";for sn in `ls -1 $fs/.zfs/snapshot`;do find $fs/.zfs/snapshot/$sn -name "file3.txt";done;done | sort | xargs ls -l 
-rw-r--r-- 1 root root 32 Nov 26 21:18 /mypool/clonedemo/file3.txt
-rw-r--r-- 1 root root 68 Nov 26 21:18 /mypool/testarea/file3.txt
-rw-r--r-- 1 root root 25 Nov 26 21:18 /mypool/testarea/.zfs/snapshot/file1-5.txt-erzeugt/file3.txt
-rw-r--r-- 1 root root 68 Nov 26 21:18 /mypool/testarea/.zfs/snapshot/file3.txt-geaendert/file3.txt

Auf diese Art und Weise kann auf sämtliche referenzierbaren Stände der Datei file3.txt zugegriffen werden.

send/recv

Vollständige Datensicherung

zfs send ist dazu imstande, die Daten eines Dateisystems (eines Snapshots, um genau zu sein) und optional mit allen Vorgänger-Snapshots und sogar rekursiv mit allen hierarchisch untergeordneten Dateisystemen in einen Datenstrom (oder eine Datei) zu schreiben, die von zfs receive, das auch mit zfs recv abgekürzt werden kann, wieder eingelesen werden kann, um diesen Snapshot (normalerweise in einem anderen Pool) wiederherstellen zu können. Dies wird im folgenden beispielhaft an einem Dateisystem vorgeführt.

## Bei der hier vorgeführten Methode muss das Zieldateisystem bereits vorhanden sein
zfs create mypool/receivedemo
zfs send -R mypool/testarea@file1-5.txt-erzeugt | zfs recv -F mypool/receivedemo
zfs list -t all 
NAME                                     USED  AVAIL  REFER  MOUNTPOINT
mypool                                  1.50M   157M    33K  /mypool
mypool/clonedemo                           1K   157M   423K  /mypool/clonedemo
mypool/receivedemo                       466K   157M   422K  /mypool/receivedemo
mypool/receivedemo@varlog-importiert      26K      -   420K  -
mypool/receivedemo@file1-5.txt-erzeugt  18.5K      -   422K  -
mypool/testarea                          500K   157M   426K  /mypool/testarea
mypool/testarea@varlog-importiert         27K      -   420K  -
mypool/testarea@file1-5.txt-erzeugt     18.5K      -   423K  -
mypool/testarea@file3.txt-geaendert     19.5K      -   424K  -

Man beachte bitte, dass das Dateisystem clonedemo zwar aus einem Snapshot erzeugt worden ist, aber (noch) keine eigenen Snapshots aufweist, während receivedemo die Snapshots von testarea aufweist, die dem kopierten Zustand vorausgingen.

Inkrementelle Sicherung

Nun befinden sich in /mypool/testarea und in /mypool/receivedemo unterschiedliche Stände:

find /mypool/ -maxdepth 2 | sort 
/mypool/
/mypool/clonedemo
/mypool/clonedemo/file1.txt
/mypool/clonedemo/file2.txt
/mypool/clonedemo/file3.txt
/mypool/clonedemo/file4.txt
/mypool/clonedemo/file5.txt
/mypool/clonedemo/log
/mypool/receivedemo
/mypool/receivedemo/file1.txt
/mypool/receivedemo/file2.txt
/mypool/receivedemo/file3.txt
/mypool/receivedemo/file4.txt
/mypool/receivedemo/file5.txt
/mypool/receivedemo/log
/mypool/testarea
/mypool/testarea/file1.txt
/mypool/testarea/file2.txt
/mypool/testarea/file3.txt
/mypool/testarea/file4.txt
/mypool/testarea/file5.txt
/mypool/testarea/file6.txt
/mypool/testarea/file7.txt
/mypool/testarea/file8.txt
/mypool/testarea/log

Diese nun zu synchronisieren, ist sehr einfach. Es bedarf nur eines aktuellen Snapshots von testarea. Ist der aktuell letzte Snapshot noch aktuell?

zfs diff  mypool/testarea@file3.txt-geaendert 

M	/mypool/testarea/
M	/mypool/testarea/file3.txt
+	/mypool/testarea/file6.txt
+	/mypool/testarea/file7.txt
+	/mypool/testarea/file8.txt

Also nicht! Zwecks Aktualisierung also noch einen anlegen:

zfs snap mypool/testarea@aktuell
## -F ist hier notwendig, weil in receivedemo eine Änderung zuvor zurück gefahren werden muss (rollback)
zfs send -R -I @file1-5.txt-erzeugt mypool/testarea@aktuell  | zfs recv -Fv mypool/receivedemo
zfs list -t all
for fs in /mypool/*;do find $fs -name "*.txt";for sn in `ls -1 $fs/.zfs/snapshot`;do find $fs/.zfs/snapshot/$sn -name "*.txt" ;done;done | sort | xargs ls -l 
NAME                                     USED  AVAIL  REFER  MOUNTPOINT
mypool                                  1.35M   158M    33K  /mypool
mypool/clonedemo                        31.5K   158M   396K  /mypool/clonedemo
mypool/receivedemo                       476K   158M   399K  /mypool/receivedemo
mypool/receivedemo@varlog-importiert      26K      -   394K  -
mypool/receivedemo@file1-5.txt-erzeugt  18.5K      -   396K  -
mypool/receivedemo@file3.txt-geaendert    18K      -   396K  -
mypool/receivedemo@aktuell                  0      -   399K  -
mypool/testarea                          476K   158M   399K  /mypool/testarea
mypool/testarea@varlog-importiert         26K      -   394K  -
mypool/testarea@file1-5.txt-erzeugt     18.5K      -   396K  -
mypool/testarea@file3.txt-geaendert       18K      -   396K  -
mypool/testarea@aktuell                     0      -   399K  -
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/clonedemo/file1.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/clonedemo/file2.txt
-rw-r--r-- 1 root root 32 Nov 26 22:31 /mypool/clonedemo/file3.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/clonedemo/file4.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/clonedemo/file5.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/receivedemo/file1.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/receivedemo/file2.txt
-rw-r--r-- 1 root root 68 Nov 26 22:30 /mypool/receivedemo/file3.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/receivedemo/file4.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/receivedemo/file5.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/receivedemo/file6.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/receivedemo/file7.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/receivedemo/file8.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/receivedemo/.zfs/snapshot/aktuell/file2.txt
-rw-r--r-- 1 root root 68 Nov 26 22:30 /mypool/receivedemo/.zfs/snapshot/aktuell/file3.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/receivedemo/.zfs/snapshot/aktuell/file5.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/receivedemo/.zfs/snapshot/file1-5.txt-erzeugt/file2.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/receivedemo/.zfs/snapshot/file1-5.txt-erzeugt/file3.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/receivedemo/.zfs/snapshot/file1-5.txt-erzeugt/file5.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/receivedemo/.zfs/snapshot/file3.txt-geaendert/file2.txt
-rw-r--r-- 1 root root 68 Nov 26 22:30 /mypool/receivedemo/.zfs/snapshot/file3.txt-geaendert/file3.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/receivedemo/.zfs/snapshot/file3.txt-geaendert/file5.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/file1.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/file2.txt
-rw-r--r-- 1 root root 68 Nov 26 22:30 /mypool/testarea/file3.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/file4.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/file5.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/file6.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/file7.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/file8.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/.zfs/snapshot/aktuell/file2.txt
-rw-r--r-- 1 root root 68 Nov 26 22:30 /mypool/testarea/.zfs/snapshot/aktuell/file3.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/.zfs/snapshot/aktuell/file5.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/.zfs/snapshot/file1-5.txt-erzeugt/file1.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/.zfs/snapshot/file1-5.txt-erzeugt/file2.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/.zfs/snapshot/file1-5.txt-erzeugt/file3.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/.zfs/snapshot/file1-5.txt-erzeugt/file4.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/.zfs/snapshot/file1-5.txt-erzeugt/file5.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/.zfs/snapshot/file3.txt-geaendert/file1.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/.zfs/snapshot/file3.txt-geaendert/file2.txt
-rw-r--r-- 1 root root 68 Nov 26 22:30 /mypool/testarea/.zfs/snapshot/file3.txt-geaendert/file3.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/.zfs/snapshot/file3.txt-geaendert/file4.txt
-rw-r--r-- 1 root root 25 Nov 26 22:30 /mypool/testarea/.zfs/snapshot/file3.txt-geaendert/file5.txt

Festplattenschaden vortäuschen

Nach diesem Ausflug in einige Operationen an/mit Dateisystemen soll noch einmal auf Pool-bezogene Aktionen hingewiesen werden, damit die Selbstheilungskräfte von ZFS gezeigt werden können. Zur Erinnerung: Der Pool besteht derzeit aus 2 vdevs, die jeweils redundant (als Spiegel) ausgelegt sind. Zunächst wird gezeigt, dass der Pool auch ohne Redundanz funktioniert.

Festplatten vom Pool trennen

Hinweis:

zpool offline nimmt die "Platte" nicht aus dem Pool, sondern erlaubt es, sie zeitweilig vom Rechner zu trennen. Um die Redundanz permanent aufzuheben, gibt es zpool detach. 

zpool status 

zpool status
  pool: mypool
 state: ONLINE
  scan: none requested
config:

	NAME                                STATE     READ WRITE CKSUM
	mypool                              ONLINE       0     0     0
	  mirror-0                          ONLINE       0     0     0
	    /mnt/free-space/simulate.disk1  ONLINE       0     0     0
	    /mnt/free-space/simulate.disk3  ONLINE       0     0     0
	  mirror-1                          ONLINE       0     0     0
	    /mnt/free-space/simulate.disk2  ONLINE       0     0     0
	    /mnt/free-space/simulate.disk4  ONLINE       0     0     0
zpool offline mypool /mnt/free-space/simulate.disk{3,4}
zpool status 

  pool: mypool
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
	Sufficient replicas exist for the pool to continue functioning in a
	degraded state.
action: Online the device using 'zpool online' or replace the device with
	'zpool replace'.
  scan: none requested
config:

	NAME                                STATE     READ WRITE CKSUM
	mypool                              DEGRADED     0     0     0
	  mirror-0                          DEGRADED     0     0     0
	    /mnt/free-space/simulate.disk1  ONLINE       0     0     0
	    /mnt/free-space/simulate.disk3  OFFLINE      0     0     0
	  mirror-1                          DEGRADED     0     0     0
	    /mnt/free-space/simulate.disk2  ONLINE       0     0     0
	    /mnt/free-space/simulate.disk4  OFFLINE      0     0     0

Dieser Pool steht nach wie vor zur Verfügung, auch wenn ihm eine Platte fehlt:

cp -R /var/log /mypool/testarea
zfs list -t snapshot 
NAME                                     USED  AVAIL  REFER  MOUNTPOINT
mypool/receivedemo@varlog-importiert      26K      -   420K  -
mypool/receivedemo@file1-5.txt-erzeugt  18.5K      -   422K  -
mypool/receivedemo@file3.txt-geaendert  18.5K      -   422K  -
mypool/receivedemo@aktuell                  0      -   426K  -
mypool/testarea@varlog-importiert         27K      -   420K  -
mypool/testarea@file1-5.txt-erzeugt     18.5K      -   423K  -
mypool/testarea@file3.txt-geaendert     19.5K      -   424K  -
mypool/testarea@aktuell                   34K      -   426K  -

Deutlich wird hier, dass mypool/receivedemo@aktuell keine Daten referenziert, weil das Dateisystem noch synchron mit diesem Snapshot ist. Demgegenüber referenziert mypool/testarea@aktuell 34K (von 426K), die sich im Dateisystem durch das erneute Kopieren von /var/log verändert haben.

Nun wird eine "Platte" wieder angeschlossen, und ZFS synchronisiert diese Unterschiede selbständig:

zpool online mypool /mnt/free-space/simulate.disk3
zpool status 
  pool: mypool
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
	Sufficient replicas exist for the pool to continue functioning in a
	degraded state.
action: Online the device using 'zpool online' or replace the device with
	'zpool replace'.
  scan: resilvered 15K in 0h0m with 0 errors on Tue Nov 26 21:17:43 2013
config:

	NAME                                STATE     READ WRITE CKSUM
	mypool                              DEGRADED     0     0     0
	  mirror-0                          ONLINE       0     0     0
	    /mnt/free-space/simulate.disk1  ONLINE       0     0     0
	    /mnt/free-space/simulate.disk3  ONLINE       0     0     0
	  mirror-1                          DEGRADED     0     0     0
	    /mnt/free-space/simulate.disk2  ONLINE       0     0     0
	    /mnt/free-space/simulate.disk4  OFFLINE      0     0     0

errors: No known data errors

Eine Platte fehlt noch im Pool, die andere ist wieder synchron (siehe die Zeile "resilvered 15K ...:" Daten und Metadaten).

Festplatten ersetzen

Die "andere Platte" sei inzwischen "herunter gefallen" oder völlig defekt. Wenn man ein Austauschgerät besorgt hat, kann man ZFS dieses als Ersatz anbieten:

truncate /mnt/free-space/simulate.disk5 -s 100M
zpool replace mypool /mnt/free-space/simulate.disk4 /mnt/free-space/simulate.disk5
zpool status 
  pool: mypool
 state: ONLINE
  scan: resilvered 15K in 0h0m with 0 errors on Tue Nov 26 21:17:43 2013
config:

	NAME                                STATE     READ WRITE CKSUM
	mypool                              ONLINE       0     0     0
	  mirror-0                          ONLINE       0     0     0
	    /mnt/free-space/simulate.disk1  ONLINE       0     0     0
	    /mnt/free-space/simulate.disk3  ONLINE       0     0     0
	  mirror-1                          ONLINE       0     0     0
	    /mnt/free-space/simulate.disk2  ONLINE       0     0     0
	    /mnt/free-space/simulate.disk5  ONLINE       0     0     0

errors: No known data errors

Auch hier: resilvered 1.1 M...

Selbstverständlich sind unzählige alternative Szenarien denkbar. Hier wurde gezeigt, wie einfach es ist, solche Vorfälle zu "simulieren" und eigene Erfahrungen und Vertrauen zu sammeln.

Festplatten verwechseln

Zum Schluss noch eine Kleinigkeit: Aufgrund des bei Ubuntu vorhandenem parallelisiertem Bootvorgang mittels Upstart kann die Reihenfolge, in der Festplatten im System auftauchen, nicht vorhergesagt werden. Dies wird hier dadurch simuliert, dass den simulate.disk-Dateien willkürlich andere Namen zugewiesen werden:

## Falls das Arbeitsverzeichnis noch "im Pool" liegen sollte
cd /
## hängt alle Dateisysteme und Volumes aus und lässt die Geräte los, die zu dem Pool gehören
zpool export mypool
cd /mnt/free-space
mv simulate.disk1 simulate.disk9a
mv simulate.disk2 simulate.disk8a
mv simulate.disk3 simulate.disk9b
mv simulate.disk5 simulate.disk8b
zpool import -d /mnt/free-space/ mypool
zpool status 

  pool: mypool
 state: ONLINE
  scan: resilvered 15K in 0h0m with 0 errors on Tue Nov 26 21:17:43 2013
config:

	NAME                                 STATE     READ WRITE CKSUM
	mypool                               ONLINE       0     0     0
	  mirror-0                           ONLINE       0     0     0
	    /mnt/free-space/simulate.disk9a  ONLINE       0     0     0
	    /mnt/free-space/simulate.disk9b  ONLINE       0     0     0
	  mirror-1                           ONLINE       0     0     0
	    /mnt/free-space/simulate.disk8a  ONLINE       0     0     0
	    /mnt/free-space/simulate.disk8b  ONLINE       0     0     0

errors: No known data errors

ZFS hat also selbständig erkannt, welche "Platte" wohin gehört und den Pool wieder bereit gestellt.

Root-Shell schließen

Nicht vergessen: Zum Abschluss die Root-Shell, die oben mit sudo -i geöffnet wurde, verlassen:

exit

Problembehebung

Verschlüsselung

Die ZFS on Linux zugrundeliegende ZFS-Version 28 kennt keine Verschlüsselung, die proprietäre Weiterentwicklung Oracle ZFS dagegen schon.

Live-CD mit ZFS

Für Ubuntu bisher nicht vorhanden, aber der Debian-Entwickler John Goerzen bietet eine Debian GNU/Linux ZFS Rescue Disc {en} an. Mehr Informationen und interessante Beiträge zu ZFS sind im Blog {en} von John zu finden, z.B. Why and how to run ZFS on Linux {en}.

Intern

./openzfs_logo.png

Extern

Diese Revision wurde am 17. Dezember 2016 01:15 von aasche erstellt.

  1. Wiki
  2. ZFS on Linux