ZFS on Linux
Archivierte Anleitung
Dieser Artikel wurde archiviert. Das bedeutet, dass er nicht mehr auf Richtigkeit überprüft oder anderweitig gepflegt wird. Der Inhalt wurde für keine aktuell unterstützte Ubuntu-Version getestet. Wenn du Gründe für eine Wiederherstellung siehst, melde dich bitte in der Diskussion zum Artikel. Bis dahin bleibt die Seite für weitere Änderungen gesperrt.
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:
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 🇬🇧 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 🇬🇧 (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 🇩🇪, Pro-Linux.de, 09/2014).
zfs-fuse¶
Bevor ZoL Form angenommen hat, existierte mit zfs-fuse 🇬🇧 (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 ⮷. 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 🇩🇪, FreeNAS (ab Version 8.x) und NAS4Free 🇬🇧 (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 🇬🇧, 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
Befehl zum Installieren der Pakete:
sudo apt-get install software-properties-common linux-headers dkms
Oder mit apturl installieren, Link: apt://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 🇬🇧 nutzen oder den Quelltext selbst kompilieren (zu Letzterem siehe Links). Für Erläuterungen zur Installation sei auch auf die sehr gute FAQ 🇬🇧 des ZoL-Projekts verwiesen.
Erst ab Ubuntu 16.04 sind die entsprechenden ZFS-Komponenten in den offiziellen Paketquellen enthalten (siehe auch ZFS 🇬🇧):
zfsutils-linux
Befehl zum Installieren der Pakete:
sudo apt-get install zfsutils-linux
Oder mit apturl installieren, Link: apt://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 
PPA-Beschreibung des Eigentümers/Teams zfs-native zu entnehmen.
Nach dem Aktualisieren der Paketquellen kann das folgende Paket installiert [2] werden:
ubuntu-zfs (ppa)
Befehl zum Installieren der Pakete:
sudo apt-get install ubuntu-zfs
Oder mit apturl installieren, Link: apt://ubuntu-zfs
Nun wird automatisch:
der aktuelle Quellcode heruntergeladen und
mit Hilfe von DKMS kompiliert (der Vorgang dauert ein wenig)
daily¶
Speziell für Entwickler gedacht war das PPA zfs-native/daily 🇬🇧. 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 mitashift=12die Sektoren des ZFS ebenfalls auf diese Größe festgelegt, um Performance-Einbußen zu vermeiden. Durch die Identifizierung der Platten mittels/dev/by-idwird 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 ...stattzpool 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/recveingesetzt wird, bedenke man die Verwendung des-iSchalters (inkrementell). Das kann einen höchst erstaunlichen Zeitgewinn mit sich bringen.
zfs sendist einemrsync-basierten Ansatz überlegen, weilzfs senddie 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-shellusw. 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 destroykann eine Unterbrechung des Zugriffs auf andere Dateisysteme verursachen. Einzfs destroywird 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 Optionasync-destroyeingefü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
zfsgeladen wird. Wenn vielezfs-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 Eintragoptions 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
17179869184für 16 GiB,8589934592für 8 GiB,4294967296für 4 GiB oder1073741824für 1 GiB. Da der ARC beim Laden des Kernelmoduls gesetzt wird, wird anschließend ein Neustart empfohlen.
In neueren Ubuntu-Versionen muss der maximale bzw. minimale Wert für des RAM Nutzung des ARC hexadezimal angegeben werden. Das Skript calc_arc.sh wandelt einen angegebenen dezimalen Gigabyte-Wert in einen hexadezimalen Wert um:
1 2 3 4 5 | #!/bin/bash numGigs=$1 decVal=$((${numGigs}*(2**30))); HEXVAL=`echo "obase=16;ibase=10; ${decVal}" | bc` echo "0x${HEXVAL}" |
Der obige Befehl zum Setzen des arc_max-Wertes in der Datei /etc/modprobe.d/zfs.conf lautet also wie folgt:
1 | options zfs zfs_arc_max=0x80000000 |
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 ⮷ 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 mypoolgefolgt von einem etwas komplexerenzpool 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 Dateisystem einzuhängen. Das hat ZFS bereits automatisch 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 nur Beispiele zu den häufigsten Einsatzzwecken von Snapshots 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 und 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.
Automatische Snapshots¶
Das script zfs-auto-snapshot erstellt Cronjobs, die automatisch Snapshots erstellen und alte Snapshots löschen. Das geschieht standardmäßig mit folgender Häufigkeit:
Alle 15 Minuten, die 4 neuesten Snapshots werden behalten
Jede Stunde, die 24 neuesten Snapshots werden behalten
Jeden Tag, die 31 neuesten Snapshots werden behalten
Jede Woche, die 8 neuesten Snapshots werden behalten
Jeden Monat, die 12 neuesten Snapshots werden behalten
Diese Parameter können verändert werden, indem man die Befehle in /etc/cron.*/zfs-auto-snapshot anpasst. Will man zum Beispiel die Snapshots der letzten zwölf Wochen behalten, ändert man den Wert für --keep in /etc/cron.weekly/zfs-auto-snapshot auf 12:
1 2 | #!/bin/sh exec zfs-auto-snapshot --quiet --syslog --label=weekly --keep=12 // |
Die Beschreibung der Optionen liefert man zfs-auto-snapshot.
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 🇬🇧 an. Mehr Informationen und interessante Beiträge zu ZFS sind im Blog 🇬🇧 von John zu finden, z.B. Why and how to run ZFS on Linux 🇬🇧.
Links¶
Intern¶
Btrfs-Dateisystem - Neuentwicklung, die einige der Fähigkeiten von ZFS beherrscht; siehe auch
Dateisystem Übersichtsartikel
Extern¶
ZFS on Linux 🇬🇧
FAQ 🇬🇧 - häufige Fragen und Antworten
ZFS Google Group 🇬🇧 - mit Beteiligung der ZoL-Entwickler
The Zettabyte File System 🇬🇧 ⮷ - interessanter Grundlagen-Artikel der ZFS-Entwickler im PDF-Format, 2004
Using the ZFS next-gen filesystem on Linux 🇬🇧 - Blogbeitrag, 02/2014
18-teilige Artikelserie von Aaron Toponce 🇬🇧 zur ZPOOL- und ZFS-Administration:
Part 0: Install ZFS on Debian GNU/Linux 🇬🇧 - 04/2012 ff.
Part XVII: Best Practices and Caveats 🇬🇧 - 01/2013
OpenZFS 🇬🇧 (siehe auch heise Open Source 🇩🇪, 09/2013)
How ZFS continues to be better than btrfs 🇬🇧 - Blogbeitrag, 06/2013
Dateisystem ZFS on Linux bereit für Alltagseinsatz 🇩🇪 - heise Open Source 04/2013
ZFS unter Ubuntu 🇩🇪 - Installation aus dem Quelltext und Nutzungsbeispiele, Blogbeitrag 08/2011 (archivierte Version von Archive.org)
RAID-Z Performance Considerations 🇬🇧 - Blogbeitrag 06/2010
A read performance surprise with ZFS's raidz and raidz2 🇬🇧 - Blogbeitrag 09/2008