All-Flash-Storage liefert die beste Performance, ist aber teuer. All-HDD-Storage bietet Kapazität zum Sparpreis, leidet aber unter hohen Latenzen bei Random-I/O. Hybrid Storage kombiniert beide Welten: SSDs beschleunigen die kritischen Operationen, HDDs liefern die Kapazität. TrueNAS mit ZFS bietet gleich mehrere Mechanismen, um SSDs gezielt für Performance-kritische Aufgaben einzusetzen — ohne den gesamten Pool auf Flash umstellen zu müssen.

Die vier SSD-Beschleuniger in ZFS

ZFS bietet vier verschiedene Wege, SSDs in einen HDD-Pool zu integrieren. Jeder Mechanismus adressiert ein anderes Performance-Problem:

Mechanismus	Beschleunigt	Typ	Datenverlust-Risiko
ARC (RAM)	Lesezugriffe	Immer aktiv (RAM)	Keines (Cache)
L2ARC	Lesezugriffe (Overflow)	SSD-VDEV	Keines (Cache)
SLOG	Synchrone Writes	SSD-VDEV	Keines (Write-Log)
Special VDEV	Metadaten + kleine Dateien	SSD-VDEV	Pool-Verlust bei Ausfall

ARC: Der RAM-basierte Lesecache

Der Adaptive Replacement Cache (ARC) ist ZFS’ primärer Lesecache und lebt vollständig im RAM. ARC speichert häufig gelesene Blöcke und verwendet einen intelligenten Algorithmus, der sowohl Frequency (häufig gelesen) als auch Recency (kürzlich gelesen) berücksichtigt.

ARC ist immer aktiv — Sie können ihn nicht deaktivieren, nur seine Größe begrenzen:

# Aktuelle ARC-Nutzung anzeigen
arc_summary

# ARC-Größe prüfen
cat /proc/spl/kstat/zfs/arcstats | grep -E "^size|^c_max"

# ARC-Maximum setzen (in /etc/modprobe.d/zfs.conf)
# 16 GB ARC Maximum
options zfs zfs_arc_max=17179869184

Empfehlung: Investieren Sie zuerst in mehr RAM, bevor Sie L2ARC in Betracht ziehen. 128 GB RAM als ARC übertrifft jeden L2ARC auf SSD, da RAM-Latenz 100x niedriger ist als SSD-Latenz.

L2ARC: Second-Level Lesecache auf SSD

Der Level 2 ARC (L2ARC) erweitert den RAM-basierten ARC auf SSDs. Wenn der ARC voll ist und Blöcke verdrängt werden, können diese statt komplett verworfen auf den L2ARC geschrieben werden.

Wann L2ARC sinnvoll ist

L2ARC ist nur sinnvoll, wenn:

Der ARC (RAM) vollständig ausgelastet ist
Das Working Set größer als der verfügbare RAM ist
Die Workload lesedominiert ist (>80 % Reads)
Random-Read-Performance kritisch ist

L2ARC ist nicht sinnvoll für:

Sequentielle Workloads (Backup, Video-Streaming)
Write-dominierte Workloads
Systeme mit wenig RAM (<32 GB) — L2ARC verbraucht selbst ARC-Speicher für seine Indexstruktur

L2ARC konfigurieren

# L2ARC-Gerät zum Pool hinzufügen
zpool add tank cache /dev/nvme0n1

# L2ARC-Status prüfen
zpool iostat -v tank

In TrueNAS: Storage > Pools > Pool auswählen > Add VDEV > Cache.

L2ARC Sizing

RAM	Empfohlene L2ARC-Größe	ARC-Overhead für Index
64 GB	200–400 GB	ca. 1–2 GB RAM
128 GB	500 GB–1 TB	ca. 2–5 GB RAM
256 GB	1–2 TB	ca. 5–10 GB RAM

Seit OpenZFS 2.0 bleibt der L2ARC-Index auch über Reboots persistent — der L2ARC muss nach einem Neustart nicht mehr neu aufgewärmt werden.

SLOG: Write-Beschleuniger für synchrone Writes

Der Separate Log (SLOG) beschleunigt synchrone Schreibvorgänge. Bei einem synchronen Write bestätigt ZFS den Schreibvorgang erst, wenn die Daten sicher auf Disk liegen. Ohne SLOG muss ZFS bei jedem Sync-Write den gesamten Transaction-Group-Commit abwarten — das kann Millisekunden bis Sekunden dauern.

Wie SLOG funktioniert

Der SLOG nimmt den ZFS Intent Log (ZIL) auf. Der ZIL ist ein Write-Ahead-Log, das synchrone Writes zwischenspeichert:

Client sendet synchronen Write
ZFS schreibt in den ZIL auf dem SLOG (SSD — schnell)
ZFS bestätigt den Write sofort
Im Hintergrund: TXG-Commit schreibt die Daten auf den Pool (HDD — langsam)

Bei einem Stromausfall werden die Daten aus dem ZIL beim nächsten Boot replayed — kein Datenverlust.

Wann SLOG sinnvoll ist

SLOG beschleunigt nur synchrone Writes:

NFS (Standard: sync)
iSCSI (Datenbank-Workloads)
Datenbanken (PostgreSQL, MySQL mit fsync)
VMware (VMFS auf NFS/iSCSI)

SLOG ist nicht nötig für:

SMB/CIFS (Standard: async)
Lokale Dateisysteme mit async
Backup-Workloads

SLOG konfigurieren

# SLOG hinzufügen (gespiegeltes SSD-Paar empfohlen)
zpool add tank log mirror /dev/nvme0n1p1 /dev/nvme1n1p1

# SLOG-Status prüfen
zpool status tank

Kritisch: Der SLOG sollte immer gespiegelt sein. Ein SLOG-Ausfall bei ungespiegelter Konfiguration kann zu Datenverlust führen (die Daten im ZIL gehen verloren).

SLOG Sizing und Hardware

Der SLOG muss nicht groß sein — er puffert nur wenige Sekunden an Writes:

Workload	Empfohlene SLOG-Größe
Leichte NFS/iSCSI-Last	8–16 GB
Mittlere Datenbank-Last	16–32 GB
Schwere Virtualisierung	32–64 GB

Hardware-Anforderung: Der SLOG benötigt extrem hohe Write-Endurance (DWPD). Consumer-SSDs sind ungeeignet — verwenden Sie Enterprise-SSDs wie Intel Optane oder Samsung PM9A3.

Special VDEV: Metadaten auf SSD

Das Special VDEV ist der mächtigste Hybrid-Storage-Mechanismus in ZFS. Es speichert Metadaten, Dedup-Tabellen (DDT) und kleine Dateien auf einem dedizierten SSD-VDEV innerhalb des Pools.

Was das Special VDEV speichert

Metadaten: Verzeichniseinträge, Dateisystem-Attribute, Block-Pointer
Kleine Dateien: Dateien unterhalb des special_small_blocks-Schwellenwerts
Dedup-Tabellen: Falls Dedup aktiviert ist (DDT)
Dnode-Metadaten: ZFS-interne Objektbeschreibungen

Warum Metadaten auf SSD entscheidend ist

Ein ls -la auf einem Verzeichnis mit 100.000 Dateien auf einem HDD-Pool kann Sekunden dauern, weil ZFS Tausende von Metadaten-Blöcken von den Festplatten lesen muss. Mit Special VDEV auf SSD dauert die gleiche Operation Millisekunden.

Special VDEV erstellen

# Pool mit Special VDEV anlegen
zpool create tank \
  raidz2 /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf \
  special mirror /dev/nvme0n1 /dev/nvme1n1

# small_blocks Schwellenwert setzen
zfs set special_small_blocks=128K tank

# Für Datasets mit vielen kleinen Dateien höheren Wert
zfs set special_small_blocks=256K tank/documents

In TrueNAS: Storage > Pools > Add VDEV > Metadata.

Redundanz ist Pflicht

Achtung: Ein Ausfall des Special VDEV ohne Redundanz führt zum vollständigen Pool-Verlust. Das Special VDEV muss mindestens als Mirror konfiguriert sein:

# Korrekt: Gespiegeltes Special VDEV
zpool create tank \
  raidz2 /dev/sd{a..f} \
  special mirror /dev/nvme0n1 /dev/nvme1n1

# FALSCH: Einzelne SSD als Special VDEV
# zpool create tank raidz2 /dev/sd{a..f} special /dev/nvme0n1
# --> Pool-Verlust bei SSD-Ausfall!

Special VDEV Sizing

Poolkapazität	Empfohlene Special-VDEV-Größe	Begründung
20 TB	200–400 GB Mirror	Metadaten ca. 1–2 % der Daten
50 TB	400 GB–1 TB Mirror	Bei vielen kleinen Dateien mehr
100+ TB	1–2 TB Mirror	Mit small_blocks=128K deutlich mehr

Fusion Pools: Alles kombiniert

Ein Fusion Pool nutzt Special VDEV, L2ARC und SLOG gleichzeitig für maximale Hybrid-Performance:

zpool create production \
  raidz2 /dev/sd{a..f} \
  raidz2 /dev/sd{g..l} \
  special mirror /dev/nvme0n1 /dev/nvme1n1 \
  log mirror /dev/nvme2n1p1 /dev/nvme3n1p1 \
  cache /dev/nvme4n1

# Dataset-Konfiguration
zfs set special_small_blocks=128K production
zfs set recordsize=1M production/media
zfs set recordsize=16K production/database
zfs set compression=zstd production

Diese Konfiguration bietet:

Metadaten und kleine Dateien auf NVMe-SSDs (Special VDEV)
Synchrone Writes über NVMe-SLOG (gespiegelt)
Lese-Cache-Overflow auf NVMe-L2ARC
Bulk-Daten auf HDD RAIDZ2 (hohe Kapazität, guter Schutz)

Entscheidungsmatrix: Welche Konfiguration für welchen Workload?

Workload	Special VDEV	L2ARC	SLOG	Priorität
Fileserver (SMB)	Ja	Optional	Nein	Special VDEV > RAM > L2ARC
NFS Datastore (VMware)	Ja	Ja	Ja	SLOG > Special VDEV > L2ARC
Datenbank (PostgreSQL)	Ja	Ja	Ja	SLOG > L2ARC > Special VDEV
Medien-Streaming	Nein	Nein	Nein	Nur Kapazität nötig
Backup-Target	Nein	Nein	Nein	Kapazität + Compression
Gemischter Workload	Ja	Optional	Optional	Special VDEV > SLOG > L2ARC

Was die Zusatz-VDEVs tatsächlich beschleunigen

Statt konkreter Messwerte — die stark von Disks, Controller und Pool-Geometrie abhängen — hier die qualitativen Effekte, die sich in fast jedem Hybrid-Setup reproduzieren lassen:

Operation	Effekt ohne Zusatz-VDEV	Effekt mit Zusatz-VDEV
Metadaten-Zugriff (`ls -la` große Ordner)	Dutzende bis hunderte Platten-Seeks → deutlich spürbare Latenz	Trifft SSD-Special-VDEV → Größenordnungen schneller
Random Reads auf Hot Data	Durch HDD-IOPS limitiert (~100-200 pro Disk)	L2ARC liefert NVMe-IOPS bei Cache-Hits
Synchrone Writes (NFS, iSCSI, DB)	Commit muss auf HDD landen → hohe Latenz	SLOG fängt Sync-ZIL ab → Commit-Latenz auf SSD-Niveau
Sequentielle Reads/Writes auf Cold Data	Durch HDD-Durchsatz begrenzt	Praktisch identisch — Sequentiell ist nicht cache-limitiert

Wer konkrete Zahlen für die eigene Hardware braucht, sollte fio mit dem realen Workload gegen den Pool laufen lassen — vorher und nach dem Hinzufügen des Special VDEV / SLOG / L2ARC. Pauschale “35× schneller”-Zahlen aus Benchmarks anderer Systeme übertragen sich selten 1:1.

Monitoring

Überwachen Sie Ihre Hybrid-Storage-Konfiguration:

# ARC- und L2ARC-Statistiken
arc_summary

# SLOG-Aktivität (ZIL Writes)
zpool iostat -v tank 5

# Special VDEV Belegung
zpool list -v tank

DATAZONE Control bietet automatisches Monitoring aller ZFS-Beschleuniger: ARC-Hit-Rate, L2ARC-Effizienz, SLOG-Latenz und Special-VDEV-Belegung in einem Dashboard — mit Alerting bei sinkender Cache-Hit-Rate oder SLOG-Latenzspitzen.

Häufig gestellte Fragen

Kann ich ein Special VDEV nachträglich hinzufügen?

Ja. Seit OpenZFS 2.1 lässt sich ein Special VDEV zu einem bestehenden Pool hinzufügen. Bestehende Metadaten werden jedoch nicht automatisch migriert — nur neue Writes landen auf dem Special VDEV.

Was passiert, wenn die L2ARC-SSD ausfällt?

Nichts Kritisches. L2ARC ist ein reiner Cache — bei Ausfall verliert ZFS den Cache-Inhalt, alle Reads gehen wieder direkt auf die HDDs. Kein Datenverlust.

Lohnt sich Optane für SLOG?

Intel Optane bietet die niedrigste Latenz und höchste Endurance aller SSDs. Für write-intensive Workloads mit vielen Sync-Writes ist Optane die beste Wahl. Für leichte NFS-Last reicht auch eine Enterprise-NAND-SSD.

Sie planen Hybrid Storage für Ihr TrueNAS-System? Kontaktieren Sie uns — wir dimensionieren und konfigurieren Special VDEV, SLOG und L2ARC für Ihren spezifischen Workload.

TrueNAS Hybrid Storage: SSD und HDD optimal kombinieren