[[Vorlage(Archiviert)]] [[Vorlage(Fortgeschritten)]] {{{#!vorlage Wissen [:Paketquellen_freischalten/PPA: Aktivieren eines PPAs] [:Pakete_installieren: Installation von Programmen] [:Terminal: Ein Terminal öffnen] }}} [[Inhaltsverzeichnis(1)]] [[Bild(./zol_logo.png, 150, align=left)]] [wikipedia:ZFS_(Dateisystem):ZFS] (ursprünglich '''Z'''ettabyte '''F'''ile '''S'''ystem) 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 [wikipedia:Logical_Volume_Manager:Logical Volume Managers] und eines Software-[wikipedia:RAID:RAID] mit einem [wikipedia:Copy-On-Write: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 [wikipedia:Transaktion_(Informatik):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 (10^^(21)^^) Bytes erlaubt (zum Vergleich siehe [wikipedia:Binärpräfix#Vergleich:]). 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 ([#ZFS-Snapshots 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 [http://www.raid-recovery-guide.com/raid5-write-hole.aspx Write-hole-Problem] {en} bei RAID-5 umgeht und die [wikipedia:RAID-Z#RAID-Z_im_Dateisystem_ZFS: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 [wikipedia: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 [https://zfsonlinux.org/ 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 [wikipedia:Lawrence_Livermore_National_Laboratory: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 [wikipedia_en:ZFS#Comparisons: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 [prolinux:news/1/21509/aktualisierung-der-stand-von-zfs-fuer-linux.html:Der Stand von ZFS für Linux] {de}, Pro-Linux.de, 09/2014). === zfs-fuse === Bevor ZoL Form angenommen hat, existierte mit [https://zfs-on-fuse.blogspot.de/ 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: [http://ftp.redsleeve.org/pub/yum/SRPMS/extra/zfs-fuse-0.7.0.20121023-5.el6.src.rpm 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: [https://www.lacie.com/de/de/products/software/nas/nas-os-3/ MyNAS] {de}, [wikipedia:FreeNAS:] (ab Version 8.x) und [https://www.nas4free.org/ 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 [wikipedia: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 [https://distrowatch.com/weekly.php?issue=20150420#myth 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: {{{#!vorlage Paketinstallation 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 [:Wily:Ubuntu 15.10] die "Personal Package Archive" (PPAs) des Launchpad-Projekts [launchpad:zfs:] {en} nutzen oder den Quelltext selbst kompilieren (zu Letzterem siehe [#Links Links]). Für Erläuterungen zur Installation sei auch auf die sehr gute [github:zfsonlinux/zfs/wiki/faq:FAQ] {en} des ZoL-Projekts verwiesen. Erst ab [:Xenial:Ubuntu 16.04] sind die entsprechenden ZFS-Komponenten in den offiziellen Paketquellen enthalten (siehe auch [ubuntu:ZFS:] {en}): {{{#!vorlage Paketinstallation 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. {{{#!vorlage Hinweis Bitte niemals beide PPAs gleichzeitig aktivieren. }}} === stable === [[Vorlage(PPA, zfs-native/stable)]] Nach dem Aktualisieren der Paketquellen kann das folgende Paket installiert [2] werden: {{{#!vorlage Paketinstallation ubuntu-zfs, ppa }}} Nun wird automatisch: 1. der aktuelle Quellcode heruntergeladen und 1. mit Hilfe von [:DKMS:] kompiliert (der Vorgang dauert ein wenig) === daily === Speziell für Entwickler gedacht war das PPA [launchpad:~zfs-native/+archive/daily: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 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 [#Beispiele 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 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-bestehenden-Pools Erweitern des Pools]. {{{#!vorlage Experten 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 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. {{{#!vorlage Warnung Die beiden folgenden Empfehlungen stammen nicht aus der Feder von Aaron Toponce, sondern aus der Diskussion (siehe [#Links 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.[[BR]][[BR]]Aber für Ordner wie '''/home/''', '''/var/log/''' und '''/var/cache/''' kann man gut ZFS verwenden. * Niemals [wikipedia: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. {{{#!vorlage Warnung * 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 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.[[BR]][[BR]]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. 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: {{{#!code bash #!/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: {{{#!code bash 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 Nutzung]). {{{#!vorlage Hinweis Grundlage dieser Anleitung ist die Version 0.6.3 der Pakete '''zfs''' und '''spl''' (beide werden vom [:Metapakete: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. {{{#!vorlage Experten Empfohlen werden Ubuntu 12.04 oder 12.04.1 mit Kernel 3.2, die im [http://old-releases.ubuntu.com/releases/ 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: {{{#!vorlage befehl sudo -i }}} Bitte nicht vergessen, diese am Ende wieder zu [#Root-Shell-schliessen schließen]. === ZFS-Installation === {{{#!vorlage befehl 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: {{{#!vorlage befehl ## 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). {{{#!vorlage Hinweis Wer es eilig hat, kann diesen Umweg abkürzen, indem er direkt zum Abschnitt [#Abkuerzung Abkürzung] vor geht. }}} Aller Anfang ist klein: {{{#!vorlage befehl ## 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 }}} {{{#!vorlage befehl 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: {{{#!vorlage Hinweis Der folgende Befehl macht nicht das, was in diesem Fall tatsächlich erforderlich wäre. Siehe auch [#Abkuerzung Abkürzung]. }}} {{{#!vorlage befehl zpool add -f mypool /mnt/free-space/simulate.disk2 }}} Mit dem Befehl: {{{#!vorlage 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 }}} {{{#!vorlage befehl 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: {{{#!vorlage befehl 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. {{{#!vorlage befehl 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: {{{#!vorlage befehl 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: {{{#!vorlage befehl ## 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: {{{#!vorlage befehl 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: {{{#!vorlage befehl 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. {{{#!vorlage befehl 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): {{{#!vorlage befehl 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: {{{#!vorlage befehl 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: {{{#!vorlage befehl 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/ }}} {{{#!vorlage befehl 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/ }}} {{{#!vorlage befehl 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 ` ausdrücklich zugänglich gemacht wurde. {{{#!vorlage Hinweis Diese den Snapshots zugeordneten Unterverzeichnisse werden auch dynamisch wieder ausgehängt! }}} {{{#!vorlage befehl 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 [https://github.com/zfsonlinux/zfs-auto-snapshot zfs-auto-snapshot] erstellt [:Cron: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: {{{#!code bash #!/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. {{{#!vorlage befehl ## 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: {{{#!vorlage befehl 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? {{{#!vorlage befehl 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: {{{#!vorlage befehl 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 === {{{#!vorlage 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`. }}} {{{#!vorlage befehl 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 }}} {{{#!vorlage befehl 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: {{{#!vorlage befehl 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: {{{#!vorlage befehl 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: {{{#!vorlage befehl 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: {{{#!vorlage befehl ## 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: {{{#!vorlage befehl 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 [https://wiki.complete.org/ZFSRescueDisc Debian GNU/Linux ZFS Rescue Disc] {en} an. Mehr Informationen und interessante Beiträge zu ZFS sind im [https://changelog.complete.org/archives/tag/zfs Blog] {en} von John zu finden, z.B. [https://changelog.complete.org/archives/9152-why-and-how-to-run-zfs-on-linux Why and how to run ZFS on Linux] {en}. = Links = == Intern == * [:Btrfs-Dateisystem:] - Neuentwicklung, die einige der Fähigkeiten von ZFS beherrscht; siehe auch * [:Dateisystem:] {Übersicht} Übersichtsartikel [[Bild(./openzfs_logo.png, 135, align=right)]] == Extern == * [https://zfsonlinux.org/ ZFS on Linux] {en} * [github:zfsonlinux/zfs/wiki/faq:FAQ] {en} - häufige Fragen und Antworten * [https://groups.google.com/a/zfsonlinux.org/group/zfs-discuss/topics ZFS Google Group] {en} - mit Beteiligung der ZoL-Entwickler * [https://users.soe.ucsc.edu/~scott/courses/Fall04/221/zfs_overview.pdf The Zettabyte File System] {en} {dl} - interessanter Grundlagen-Artikel der ZFS-Entwickler im PDF-Format, 2004 * [http://open-zfs.org/wiki/History Eckdaten zur ZFS-Entwicklung] {en} * [https://arstechnica.com/information-technology/2014/02/ars-walkthrough-using-the-zfs-next-gen-filesystem-on-linux/ Using the ZFS next-gen filesystem on Linux] {en} - Blogbeitrag, 02/2014 * 18-teilige Artikelserie von [https://pthree.org/category/zfs/ Aaron Toponce] {en} zur ZPOOL- und ZFS-Administration: * [https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux/ Part 0: Install ZFS on Debian GNU/Linux] {en} - 04/2012 ff. * [https://pthree.org/2013/01/03/zfs-administration-part-xvii-best-practices-and-caveats/ Part XVII: Best Practices and Caveats] {en} - 01/2013 * [wikipedia_en:ZFS:] * [http://open-zfs.org/ OpenZFS] {en} (siehe auch [heise:-1960413:heise Open Source] {de}, 09/2013) ##datenninja: Dieser Link ist BEWUSST auf den zu Solaris 10 gehörigen Guide, denn in Solaris 11 wurden neue Dinge (wie z.B. encryption) zu ZFS hinzugefügt, die ZoL nicht hat * [https://docs.oracle.com/cd/E26505_01/html/E37384/index.html Oracle Solaris 10 ZFS Administration Guide] {en} * [https://java.net/projects/solaris-zfs/pages/Home ältere Linksammlung zum Thema ZFS] {en} * [https://rudd-o.com/linux-and-free-software/ways-in-which-zfs-is-better-than-btrfs How ZFS continues to be better than btrfs ] {en} - Blogbeitrag, 06/2013 * [heise:-1833105:Dateisystem ZFS on Linux bereit für Alltagseinsatz] {de} - heise Open Source 04/2013 * [https://web.archive.org/web/20131222085058/http://www.hack-job.org/how-tos/zfs-unter-ubuntu ZFS unter Ubuntu] {de} - Installation aus dem Quelltext und Nutzungsbeispiele, Blogbeitrag 08/2011 (archivierte Version von Archive.org) * [wikipedia:RAID-Z#RAID-Z_im_Dateisystem_ZFS:] * [https://constantin.glez.de/blog/2010/06/closer-look-zfs-vdevs-and-performance#raidzperformance RAID-Z Performance Considerations] {en} - Blogbeitrag 06/2010 * [https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSRaidzReadPerformance A read performance surprise with ZFS's raidz and raidz2] {en} - Blogbeitrag 09/2008 ## * [heise:-221631:OpenSolaris als Fileserver] {de} - Einsatz von ZFS in der Praxis, heise Open Source 12/2008 # tag: System, Dateisystem