ZFS-Pools auf rotierenden Festplatten liefern beeindruckenden sequentiellen Durchsatz, kämpfen aber mit synchronen Schreiboperationen. Jeder Sync Write muss auf nicht-flüchtigem Speicher landen, bevor ZFS die Operation bestätigt — und bei HDDs bedeutet das: warten auf die Plattenrotation. SLOG (Separate Intent Log) und Special VDEV sind zwei ZFS-Funktionen, die dieses Problem gezielt lösen.

ZFS Intent Log (ZIL) verstehen

Bevor wir über SLOG sprechen, müssen wir den ZIL verstehen. Der ZFS Intent Log ist ein Mechanismus, der synchrone Schreiboperationen absichert. Bei einem Sync Write passiert Folgendes:

Die Daten werden in den ZIL geschrieben
ZFS bestätigt den Write an die Anwendung
Im Hintergrund werden die Daten im nächsten Transaction Group (TXG) Commit an ihren endgültigen Platz im Pool geschrieben
Nach dem TXG-Commit wird der ZIL-Eintrag freigegeben

Der ZIL existiert immer — er ist ein fester Bestandteil jedes ZFS-Pools. Standardmäßig liegt er auf den Pool-Disks selbst. Das Problem: Wenn der ZIL auf den gleichen HDDs liegt wie die Daten, konkurrieren ZIL-Writes mit regulären I/O-Operationen.

Wann werden Sync Writes verwendet?

Nicht jede Anwendung nutzt Sync Writes. Die wichtigsten Szenarien:

Protokoll/Anwendung	Sync Writes?	Grund
NFS (sync=standard)	Ja	NFS-Standard erfordert sync
iSCSI	Ja	Block-Level-Protokoll, sync by default
SMB (Durable Handles)	Teilweise	Abhängig von Client und Konfiguration
Datenbanken (PostgreSQL, MySQL)	Ja	fsync() für Transaktionssicherheit
VMs auf ZFS (zvol)	Ja	Gast-OS erwartet sync-Bestätigung
Lokale Dateioperationen	Nein (meist)	async by default

SLOG: Das Separate Intent Log

Ein SLOG ist ein dediziertes Gerät, auf das der ZIL ausgelagert wird. Statt auf den langsamen Pool-Disks landet der ZIL auf einem schnellen NVMe- oder Optane-Gerät.

Was ein SLOG braucht (und was nicht)

SLOG braucht:

Extrem hohe IOPS (4K Random Write)
Sehr niedrige Latenz (< 100 Mikrosekunden ideal)
Power-Loss Protection (PLP) — absolut kritisch
Moderate Kapazität (8–32 GB genügen meist)

SLOG braucht NICHT:

Hohen sequentiellen Durchsatz
Große Kapazität (der ZIL hält Daten nur Sekunden)
Hohe Lebensdauer (TBW ist selten ein Problem)

Warum so wenig Kapazität?

Der ZIL speichert Daten nur bis zum nächsten TXG-Commit (standardmäßig alle 5 Sekunden). Danach werden die Daten an ihren endgültigen Platz verschoben und der ZIL-Eintrag gelöscht. Selbst bei hoher Sync-Write-Last sammeln sich selten mehr als einige Gigabyte an.

Die Faustregel:

SLOG-Kapazität ≈ Maximaler Sync-Write-Durchsatz × TXG-Timeout × 2

Beispiel: 500 MB/s Sync-Writes × 5 Sekunden × 2 (Sicherheitspuffer) = 5 GB. Ein 16-GB-SLOG reicht für die allermeisten Workloads.

SLOG einrichten

# SLOG-Gerät dem Pool hinzufügen
zpool add tank log /dev/nvme0n1

# SLOG im Mirror für Redundanz (empfohlen)
zpool add tank log mirror /dev/nvme0n1 /dev/nvme1n1

# Pool-Status prüfen
zpool status tank

Ausgabe:

  pool: tank
 state: ONLINE
config:
    NAME                    STATE
    tank                    ONLINE
      raidz2-0              ONLINE
        da0                 ONLINE
        da1                 ONLINE
        da2                 ONLINE
        da3                 ONLINE
        da4                 ONLINE
        da5                 ONLINE
    logs
      mirror-1              ONLINE
        nvme0n1             ONLINE
        nvme1n1             ONLINE

SLOG-Performance messen

Messen Sie den Unterschied vor und nach dem SLOG-Einbau:

# Sync-Write-Performance testen (ohne SLOG)
fio --name=sync-write --rw=randwrite --bs=4k --size=1G \
    --numjobs=8 --sync=1 --direct=1 --filename=/tank/testfile

# Nach SLOG-Installation erneut testen
# Erwartung: 5–50x mehr IOPS bei Sync Writes

Power-Loss Protection: Nicht verhandelbar

Ein SLOG ohne PLP ist schlimmer als kein SLOG. Der Grund: ZFS bestätigt den Sync Write, sobald die Daten im ZIL (auf dem SLOG) gelandet sind. Verliert das SLOG-Gerät bei einem Stromausfall Daten, die noch nicht in den Pool geschrieben wurden, sind diese Daten unwiederbringlich verloren — und ZFS hat der Anwendung bereits bestätigt, dass der Write sicher ist.

Geräte mit PLP:

Intel Optane (alle Modelle)
Enterprise-NVMe mit PLP (z. B. Samsung PM9A3, Micron 7450)
Enterprise-SATA-SSDs (z. B. Intel S4610, Samsung PM893)

Geräte OHNE PLP (nicht als SLOG verwenden):

Consumer-NVMe (Samsung 990 Pro, WD Black SN850X)
Consumer-SATA-SSDs (Samsung 870 EVO, Crucial MX500)

Special VDEV: Metadaten beschleunigen

Das Special VDEV ist eine neuere ZFS-Funktion (ab OpenZFS 0.8), die einen anderen Engpass adressiert: Metadaten und kleine Blöcke. ZFS speichert Metadaten (Verzeichnisstrukturen, Dateiattribute, Deduplizierungstabellen) standardmäßig auf den Pool-Disks. Bei großen Pools mit Millionen von Dateien werden Metadaten-Lookups zum Flaschenhals.

Was das Special VDEV speichert

Ein Special VDEV übernimmt:

Metadaten (Dnode-Blöcke, Verzeichnisinhalte, Dateisystem-Metadaten)
Kleine Datenblöcke (konfigurierbar über special_small_blocks_threshold)
Deduplizierungstabellen (DDT — bei aktivierter Dedup)

Special VDEV einrichten

# Special VDEV hinzufügen (Mirror empfohlen)
zpool add tank special mirror /dev/nvme2n1 /dev/nvme3n1

# Schwellenwert für kleine Blöcke setzen (z. B. 128 KB)
zfs set special_small_blocks=128k tank

# Pool-Status prüfen
zpool status tank

Ausgabe:

  pool: tank
 state: ONLINE
config:
    NAME                    STATE
    tank                    ONLINE
      raidz2-0              ONLINE
        da0 ... da5         ONLINE
    logs
      mirror-1              ONLINE
        nvme0n1             ONLINE
        nvme1n1             ONLINE
    special
      mirror-2              ONLINE
        nvme2n1             ONLINE
        nvme3n1             ONLINE

Sizing des Special VDEVs

Das Special VDEV braucht deutlich mehr Kapazität als ein SLOG, da Metadaten permanent gespeichert werden:

Special VDEV Kapazität ≈ Pool-Kapazität × Metadaten-Anteil + kleine Blöcke

Faustregel:

Ohne kleine Blöcke: 1–5 % der Pool-Kapazität für reine Metadaten
Mit small_blocks=128k: 5–20 % der Pool-Kapazität (abhängig vom Workload)

Für einen 100-TB-Pool:

Reine Metadaten: 1–5 TB NVMe
Mit kleinen Blöcken: 5–20 TB NVMe

Wann lohnt sich ein Special VDEV?

Szenario	Nutzen
Millionen kleiner Dateien (E-Mail, Home-Shares)	Hoch — Metadaten-Lookups werden dramatisch schneller
Wenige große Dateien (Video, Backup-Images)	Gering — kaum Metadaten-Last
Dedup aktiviert	Hoch — DDT auf NVMe ist um Größenordnungen schneller
Viele Snapshots	Mittel — Snapshot-Metadaten profitieren

Hardware-Auswahl: Intel Optane als Goldstandard

Intel Optane basiert auf 3D XPoint-Technologie und bietet Eigenschaften, die für ZFS-Log-Geräte ideal sind:

Eigenschaft	Optane P5800X	Enterprise NVMe	Consumer NVMe
4K Random Write Latenz	6 Mikrosekunden	15–30 Mikrosekunden	50–200 Mikrosekunden
4K Random Write IOPS	1.5M	200–500K	50–100K
Power-Loss Protection	Ja	Ja (Enterprise)	Nein
Endurance (DWPD)	100	1–3	0.3–1
Preis (2026)	Hoch (auslaufend)	Mittel	Niedrig

Optane-Verfügbarkeit: Intel hat die Optane-Produktion eingestellt. Restbestände sind noch verfügbar, aber die Preise steigen. Alternativen wie Samsung PM9A3 oder Kioxia FL6 bieten gute Performance mit PLP, erreichen aber nicht die Latenzwerte von Optane.

Optane-Modelle für SLOG und Special VDEV

Optane P1600X (118 GB): Ideal als SLOG — kompakt, günstig, PLP
Optane P5800X (400/800 GB): Ideal als Special VDEV — hohe Kapazität, extreme Performance
Optane 905P/900P: Ältere Generation, aber immer noch exzellent für SLOG

Risiken bei SLOG-Ausfall

SLOG fällt aus (nicht-redundant)

Wenn ein einzelner SLOG ohne Mirror ausfällt:

Pool bleibt online — ZFS fällt automatisch auf den Pool-internen ZIL zurück
Performance sinkt auf das Niveau ohne SLOG
Kein Datenverlust (solange kein Stromausfall während des Übergangs)

SLOG-Mirror fällt teilweise aus

Bei einem SLOG-Mirror mit einem ausgefallenen Gerät:

Pool bleibt online mit voller Performance
Redundanz ist weg — ersetzen Sie das defekte Gerät zeitnah

Special VDEV fällt aus

Ein ausgefallenes Special VDEV ist kritisch:

Der gesamte Pool wird unlesbar, wenn das Special VDEV verloren geht
Ein Special VDEV muss als Mirror konfiguriert werden
Erwägen Sie für kritische Daten ein 3-Way-Mirror

# Special VDEV als 3-Way-Mirror (höchste Sicherheit)
zpool add tank special mirror /dev/nvme2n1 /dev/nvme3n1 /dev/nvme4n1

Monitoring

Überwachen Sie SLOG und Special VDEV regelmäßig:

# SLOG- und Special VDEV-Status
zpool status tank

# I/O-Statistiken für Log-Geräte
zpool iostat -v tank 5

# SMART-Werte der NVMe-Geräte prüfen
smartctl -a /dev/nvme0n1

Achten Sie besonders auf:

Wear Level (Percentage Used) — bei Enterprise-NVMe meist unkritisch
Available Spare — sollte über 10 % liegen
Media Errors — sollten bei 0 bleiben

Fazit

SLOG und Special VDEV sind keine Allheilmittel, sondern gezielte Optimierungen für spezifische Engpässe. Ein SLOG lohnt sich bei hohem Sync-Write-Anteil (NFS, iSCSI, Datenbanken), ein Special VDEV bei metadatenintensiven Workloads (viele kleine Dateien, Dedup). Die richtige Hardware-Auswahl — insbesondere Power-Loss Protection — ist dabei nicht optional, sondern überlebenswichtig für die Datenintegrität.

ZFS SLOG und Special VDEV: Sync Writes beschleunigen und Metadaten optimieren