ZFS Grundlagen

Aus Thomas-Krenn-Wiki
Zur Navigation springen Zur Suche springen

ZFS (Pseudo-Akronym, fr. Abk. f. Zettabyte File System) ist ein ursprünglich von Sun Microsystems für das Betriebssystem Solaris entwickeltes Dateisystem. Das Projekt OpenZFS entwickelt eine Open-Source Variante[1]. ZFS grenzt sich von anderen Dateisystemen durch seinen Fokus auf Datenintegrität, Speicherkapazität und die Verwaltung von physischen Laufwerken in einem logischen Geräteverbund ab.

Grundfunktion

Der Hauptfokus von ZFS liegt in der Datenintegrität. Um diese zu gewährleisten, setzt ZFS auf einen transaktionalen Ansatz. Das bedeutet: Schreibvorgänge werden immer vollständig oder gar nicht ausgeführt[2].

Ein einfacher, asynchroner Schreibvorgang sammelt bzw. puffert Daten für einen festgelegten Zeitraum in einer sogenannten Transaktionsgruppe (TXG) im Arbeitsspeicher des Systems. Nach dieser Zeitspanne werden die Änderungen in den Festspeicher übertragen. Damit ist die Transaktion abgeschlossen.

Damit die Konsistenz der Daten bei diesem Vorgehen gesichert ist, verwendet ZFS eine Copy-on-Write (CoW) Strategie. Bei einem Schreibvorgang werden keine Blöcke überschrieben. Stattdessen werden die Blöcke mit den entsprechenden Änderungen an eine andere Stelle kopiert. Die alten Blöcke bleiben erhalten, das Dateisystem verweist aber auf die neuen Blöcke. Werden die alten Blöcke nicht mehr referenziert (zum Beispiel von Snapshots), können sie bei zukünftigen Schreibvorgängen überschrieben werden.

Aufbau

Abb. 1: Beispielhafte einfache Darstellung des ZFS Storage Stacks.

Um die Funktionsweise von ZFS zu verstehen, muss man dessen Bausteine verstehen.

Drei Ebenen bilden die Struktur des ZFS Storage Stacks[3] (s. Abb. 1): Die unterste Ebene sind die physischen Datenträger. Diese werden darüber in logischen Verbünden innerhalb eines Storage-Pools, dem sogenannten zpool, zusammengefasst. Über dem zpool werden dem Betriebssystem logische Objekte zur Verfügung gestellt. Neben den Datasets, die klassischen Dateisystemen entsprechen, gibt es hier auch Metadaten wie Snapshots und Bookmarks.

Die Hardware-Ebene wird in diesem Artikel nicht weiter besprochen. Wenn Sie eine Beratung zur effizienten und leistungsstarken Gestaltung einer ZFS-Infrastruktur wünschen, melden Sie sich gerne bei uns: Ansprechpartner

Daneben sind außerdem der Adaptive Replacement Cache (ARC) und das ZFS Intent Log (ZIL) wichtige Elemente für die Funktion von ZFS.

zpool

Der zpool ist ein virtueller Speicherpool, der aus den sogenannten vdevs (kurz für Virtual Devices) gebildet wird. ZFS kann mehrere zpools verwalten. Die einzelnen zpools sind dabei unabhängig voneinander und müssen auch gesondert verwaltet werden.

vdev

Ein vdev ist ein logischer Datenträger innerhalb eines zpools, der aus einem physischen Datenträger oder einem Zusammenschluss aus mehreren physischen Datenträgern erstellt wird. Er kann aus folgenden Entitäten gebildet werden:

  • Physische Datenträger
  • Datenträgerverbünde (z.B. RAID)
  • Partitionen

In Produktivumgebungen wird ein vdev üblicherweise aus einzelnen physischen Datenträgern gebildet.

Es ist auch möglich, einen vdev aus Dateien zu bilden. Das stellt aber einen Sonderfall dar und ist nur zu Testzwecken zu empfehlen.

Storage vdevs dienen der Datenspeicherung. ZFS stellt verschiedene Redundanz-Level für Storage vdevs zur Verfügung[4]:

  • Single (einfacher Datenträger)
  • Mirror (gespiegelte Datenträger)
  • RAIDZ-1/2/3 (Datenträgerverbund mit 1/2/3 Paritäten)
  • dRAID

Daneben gibt es noch weitere vdevs mit speziellen Verwendungen:

  • Spare: Wird bei Ausfall eines physischen Datenträgers aus einem Storage vdevzur Wiederherstellung (resilvering) verwendet[4]
  • Cache: Der auch als L2ARC (Level 2 Adaptive Replacement Cache) bekannte Lesepuffer ist die Erweiterung des ARC[4]
  • Log: Das auch SLOG (Separate Intent Log) genannte vdev ist für die Zwischenspeicherung bei synchronen Schreibvorgängen zuständig. Es ist die Auslagerung des ZIL (ZFS Intent Log)[4]
  • Dedup: Dieses vdev wird zur Speicherung der Deduplication Table (DDT) bei Deduplikation im zpool verwendet
  • Special: Ein vdev zur Speicherung von Metadaten und optional kleinen Datenblöcken[4]. Speichert auch die DDT, wenn dafür kein dediziertes vdev vorhanden ist

Datasets

Ein Dataset bildet die oberste Schicht des ZFS Storage Stacks. Folgende Datasets können mit ZFS gebildet werden:

  • ZVOL: Das ZFS Volume ist ein virtuelles Block Device
  • Dateisystem: Es können ZFS-eigene Dateisysteme eingerichtet werden
  • Clone: Eigenständige beschreibbare Kopie eines ZFS-Snapshots[4]

ZVOLs können dazu verwendet werden, reguläre Dateisysteme auf Betriebssystemschicht einzusetzen.

Metadaten

Neben den Datasets gibt es weitere logische Objekte in ZFS:

  • Snapshot: Ein Snapshot ist die Momentaufnahme eines Systemzustands. Die zum Zeitpunkt des Snapshots beschriebenen Blöcke sind unveränderlich (immutable) und bleiben zumindest solange erhalten, bis der Snapshot und seine Referenzen gelöscht werden[4]
  • Bookmark: Ein Bookmark ist eine schreibgeschützte Kopie eines Dateisystems bzw. eines Volumes. Sie sind an Snapshots gebunden und bleiben auch erhalten, wenn der Snapshot gelöscht wird[4]

ARC und ZIL

Neben dem Storage Stack gibt es für eine effiziente Verwendung von ZFS zwei weitere wichtige Module.

ARC

Der Adaptive Replacement Cache (ARC) ist der Lesepuffer von ZFS. Er wird im Arbeitsspeicher des Host-Systems gebildet[5].

Die grundsätzliche Aufgabe des ARC ist es, Blöcke für schnelle Lesevorgänge bereitzustellen. Dafür bildet er Listen über gepufferte Einträge[5]. Der ARC unterscheidet dabei zwischen zuletzt (MRU - Most Recently Used) verwendeten Blöcken und häufig (MFU - Most Frequently Used) verwendeten Blöcken. Der ARC ist damit schneller als üblicherweise verwendete Lesepuffer, die nur MRU im Puffer halten[6].

L2ARC

Der Level 2 ARC (L2ARC) wird im Festspeicher (vorzugsweise NVMe) gebildet[5]. Werden Daten aus dem ARC verdrängt, kann ZFS sie im L2ARC ablegen und bei späteren Lesezugriffen darauf zugreifen.

ZIL

Das ZFS Intent Log (ZIL) ist ein temporärer Zwischenspeicher, der bei synchronen Schreibvorgängen zum Einsatz kommt.

Das ZIL ist kein Cache im eigentlichen Sinn: Bei einem synchronen Schreibvorgang werden die Daten gleichzeitig in eine Transaktionsgruppe (im RAM) und in das ZIL (auf physischen Datenträgern) geschrieben[7]. Sobald die Daten aus der Transaktionsgruppe in das vdev vollständig geschrieben sind, werden die Daten im ZIL verworfen. Das ZIL sorgt damit dafür, dass die Integrität der Daten auch bei Systemausfällen erhalten bleibt. Durch den notwendigen Eintrag auf einen (im Vergleich zum Arbeitsspeicher) langsamen Festspeicher sind synchrone Schreibvorgänge dafür weniger performant.

SLOG

Das Separate Intent Log (SLOG) lagert ZIL-Blöcke auf ein separates vdev aus[8]. Das ist sinnvoll, wenn die für das SLOG verwendeten Datenträger eine höhere Schreibleistung haben.

Weitere Informationen

Offizielle Dokumentation: OpenZFS Documentation

Grundlagenartikel: ZFS 101—Understanding ZFS storage and performance

Synchrone/Asynchrone Schreibvorgänge: ZFS sync/async + ZIL/SLOG, explained

TrueNAS Artikel zu ZIL und SLOG: The ZFS ZIL and SLOG Demystified

ZFS On Linux: https://zfsonlinux.org/

Aaron Toponce zu ZFS: ZFS Administration

Einzelnachweise

  1. OpenZFS Documentation (openzfs.github.io, 2026)
  2. Transactional Semantics (docs.oracle.com, 2026)
  3. "System Administration" im openzfs Wiki (openzfs.org, 2026)
  4. 4,0 4,1 4,2 4,3 4,4 4,5 4,6 4,7 zfsconcepts.7 (openzfs.github.io, 2026)
  5. 5,0 5,1 5,2 Adaptive Replacement Cache (openzfs.github.io, 2026)
  6. OpenZFS ARC Quellcode (github.com/openzfs, 2026)
  7. OpenZFS ZIL Quellcode (github.com/openzfs, 2026)
  8. OpenZFS - Synchrone Schreibvorgänge (openzfs.github.io, 2026)

Autor: Stefan Bohn

Stefan Bohn ist seit 2020 bei der Thomas-Krenn.AG beschäftigt. Ursprünglich als Berater für IT-Lösungen im PreSales beheimatet, wechselte er 2022 zum Product Management. Dort widmet er sich dem Wissenstransfer und treibt dabei auch das Thomas-Krenn Wiki voran.