ZFS ist kein normales Dateisystem — es vereint Dateisystem, Volumemanager und RAID in einem. Keine separate Partitionierung, kein mdadm, kein LVM. Ein Befehl erstellt einen Pool, ein zweiter ein Dataset. Snapshots, Compression, Verschlüsselung und Replikation sind eingebaut. Ursprünglich von Sun Microsystems für Solaris entwickelt, läuft ZFS heute als OpenZFS auf FreeBSD, Linux und macOS.
Was ZFS anders macht
Copy-on-Write: Daten werden nie überschrieben — jede Änderung wird an eine neue Stelle geschrieben. Erst wenn der neue Block vollständig ist, wird der Zeiger umgehängt. Dadurch gibt es kein Write Hole wie bei klassischem RAID und Snapshots sind praktisch kostenlos.
Checksummen und Selbstheilung: Jeder Block hat eine Checksumme, gespeichert im übergeordneten Block (Merkle Tree). Beim Lesen wird die Checksumme geprüft — bei einem Fehler repariert ZFS den Block automatisch aus der Redundanz. Silent Data Corruption wird erkannt, bevor sie Schaden anrichtet.
Integrierter Volumemanager: ZFS weiß, welche Blöcke belegt sind und welche nicht. Beim Resilvering (Neusynchronisation nach Plattenausfall) werden nur belegte Blöcke kopiert — ein 80-GB-Mirror mit 4 GB Daten ist in Minuten fertig statt Stunden.
Technische Eckdaten
| Adressierung | 128 Bit |
| Max. Dateisystemgröße | 16 EiB (16 × 2⁶⁰ Byte) |
| Max. Poolgröße | 256 ZiB (256 × 2⁷⁰ Byte) |
| Max. Dateien pro Verzeichnis | 2⁴⁸ |
| Max. Geräte pro Pool | 2⁶⁴ |
| RAID-Level | Mirror, RAID-Z (1–3 Paritäten), Striping, Spare |
| Volumemanager | Integriert |
ZFS im Detail — die Artikelserie
Jedes Feature ist in einem eigenen Beitrag erklärt:
- ZFS Pool und Datasets erstellen — Pool anlegen, Datasets mit Quota und Mountpoint
- ZFS RAID: Mirror und RAID-Z — Redundanz konfigurieren, Root-Pool spiegeln
- ZFS Compression und Deduplication — LZ4, zstd und warum Dedup RAM frisst
- ZFS Snapshots — Erstellen, Zugreifen, Rollback und SSH-Replikation
- ZFS Encryption — GELI und OpenZFS Native Encryption
- ZFS NFS-Freigaben — sharenfs mit Zugriffskontrolle
- ZFS SMB-Freigaben — sharesmb unter Solaris/OpenIndiana
- ZFS mit NTFS-ACLs — Windows-Berechtigungen auf ZFS
- ZFS iSCSI Target — Block-Storage mit COMSTAR
- ZFS Scrub — Integritätsprüfung starten und überwachen
- ZFS Boot Environments — Sichere Updates mit Rollback
- Automatische ZFS-Snapshots — zfs-auto-snapshot und zfs-periodic
- ZFS Datensicherung — Backup-Strategie mit send/recv
- ZFS Backup auf USB-HDD — Verschlüsseltes Offsite-Backup
- ZFS send/recv Fehlerbehebung — „Cannot receive incremental stream“ lösen
Fragen? Einfach melden.
So ging es mir mit allem was man so mal eben in die Kiste stopfen kann. Ob es nun ein USB-Stick, eine CD/DVD oder eine Wechselplatte ist. Sie wird sauber erkannt und automatisch eingebunden. Es gibt ein schönes Symbol auf dem Gnome Desktop und in dessen Dateiverwaltung. Selbst der Zugriff auf alles klappt tadellos. Aber wehe man möchte das Teil wieder los werden.
Sobald man auf „Aushängen“ klickt, springt einem das System mit der GUI-Meldung an: cannot unmount volume
Sehr nervig…. Konsole aufmachen, su, unmount…..
Dass dieses ein Problem mit irgendeiner Berechtigung sein muss ist schnell klar, aber welcher? Google konnte mir schnell helfen. Das Problem besteht seit 147 bzw. Solaris Express, soll aber inzwischen gefixt sein. Ist es auch, nur taucht es inzwischen durch eine andere Änderung wieder auf. Das ganze ist bekannt und soll gelöst werden. Bisher gibt es einen Workaround.
Einfach nachstehende Zeile in die folgende Datei packen:
Der OpenSolaris fork Openindiana und gPodder
Pahhh da boote ich ganz cool meine Linux-Schüssel, hänge die USB-Platte ein und passe meine exports für einen ganz einfachen und schnellen Share an:
ZFS ist nun schon ein paar Jahre alt, denn noch habe ich bisher noch kein Dateisystem gefunden welches im wirklich das Wasser reichen kann. Hier und da in Detailvergleichen, keine Frage aber
alles in allem „no way“. Bei seiner Einführung hat SUN etwas von unkaputtbar erzählt. Titanic lässt grüßen? Auf keinen Fall… Ich habe es noch nicht geschafft ein ZFS zu zerlegen. Egal wie oft der Strom ausfällt oder der Rechner einen Reset bekommt. Ohne Hammer bzw. echten Hardwaredef. läuft das System einfach weiter.
Wie auch immer…. Vor ein paar Tagen ist nun die Entwicklerversion oi_151a erschienen. Die Version 148 war schon viel versprechend. Diese Version lief auch immer im Dualboot neben meinem Gentoo. Da sie denn noch viel Schleifarbeit an vielen Stellen braucht hatte sie eher ein passives leben 🙁
Dieses hat sich jetzt nach einem kurzen Test geändert. Gentoo verschwindet in eine Virtualbox VM auf dem Solarissystem und dann geht es los.
Ich liste in laufe der Zeit mal in einem Untermenü auf was mir so aufgefallen ist bzw. was anderen vielleicht weiterhelfen könnte.
OpenIndiana der fork von OpenSolaris und Solaris? Ja und nein, denn Sun hat sein Verspechen, die OpenSolaris-Entwicklung für die Gemeinschaft zu öffnen, nicht eingehalten hat und da Oracle nach der Übernahme von Sun zunehmend Teilprojekte einstellte, haben Mitglieder der OpenSolaris-Entwickler-Gemeinschaft am 3. August 2010 die Gründung des Projektes Illumos zur Entwicklung eines wirklich freien Open-Source-Solaris bekanntgegeben. OpenIndiana hat nun diese Basis.
Ich hatte auf einer meiner Maschinen ein kleines Problem mit der LiveCD. Diese bliebt beim booten einfach hängen und dieses ohne erkennbaren Grund. Zumindest konnte ich auf den Konsolen nichts erkennen und einen Logfile gibt es so ja erstmal nicht :-/ Bei einem Linux Live System würde man ja nun erstmal Kernel Optionen wie: noacpi / noapic / acpi=off oder so ein Geschlönz probieren, aber hier????
Ich habe im Zusammenhang mit der OpenIndiana LiveDVD ein paar Bugs und Probleme im Zusammenhang mit USB gelesen. Hier scheint das System noch etwas „anfällig“ zu sein 🙁 Wie auch immer nach einigen Tests viel mit nichts besseres mehr ein als einfach den USB-Kontroller im BIOS zu deaktivieren. Nur um das USB-System auszuschließen versteht sich… Tja, was soll ich sagen? USB im BIOS ausschalten und LiveDVD (der OpenIndiana Live USB-Stick ist dann natürlich nutzlos) einlegen. Schon versagen ordnungsgemäß USB-Tastatur und USB-Maus ihren Dienst, OpenIndiana Bootet aber sauber hoch. Spannenderweise erkennt das gebootete System den USB-Kontroller wieder und somit auch Maus, Tastatur oder sonstige USB-Sticks. Dieses Verhalten führte zwar bei mir zu etwas Stirnrunzeln, bringt mir denn noch ein funktionierendes System.