Zielsetzung
Dieses Experiment entstand aus einem praktischen Bedarf: Für meinen Heimserver – basierend auf NetBSD/Xen – sollte eine Lösung mit maximaler I/O-Performance bei minimalem Ressourcenverbrauch gefunden werden. Die Hardware ist bewusst minimalistisch: ein Intel NUC mit 512 MB RAM in der Dom0 und einer NVMe-SSD als Datenträger.
Im Fokus stand die Frage: Wie viel Performance ist unter Xen mit NetBSD realistisch, ohne dabei Flexibilität oder Stabilität zu opfern?
Testaufbau
- Hardware: Intel NUC (Dual Core Intel Celeron J4025 @ 2.00 GHz), 8 GB RAM
- Storage: 2 TB NVMe-SSD
- Hypervisor: Xen (Dom0 = NetBSD 10.1)
- DomU: paravirtualisiertes NetBSD 10.1
- Benchmark: bonnie++
- Datensätze: 16 GB, 32 GB und 400 GB
Getestet wurden verschiedene Backend-Varianten, über die die Dom0 Blockgeräte an die DomU weiterreicht:
- ZVOL (ZFS)
- RAW-Partition (FFSv2)
- VND-Image (virtuelle Diskdatei)
- CCD (Concatenated Disk)
- LVM Logical Volume
ZFS – Feature-Gigant mit Performance-Limit
ZFS bringt viele Enterprise-Features: Checksums, Snapshots, Self-Healing. Doch auf einer 512 MB-Dom0 zeigte sich schnell, dass diese Funktionen ihren Preis haben. Die Performance lag im einstelligen MB-Bereich, die Latenzen waren hoch, und teilweise kam es zu Reboots ohne Crashdump.
Messfazit: ZFS skaliert auf so kleiner Hardware nicht sinnvoll. Die Leistung bricht früh ein, und die Stabilität leidet.
Bewertung: Für ressourcenarme Umgebungen ungeeignet – der Funktionsumfang steht in keinem Verhältnis zur Performance.
FFSv2 RAW – die Performance-Referenz
Eine direkt durchgereichte GPT-Partition mit FFSv2 lieferte deutlich bessere Ergebnisse. Die Schreib- und Leseraten erreichten rund 150 MB/s bzw. 260 MB/s, mit Random-I/O-Werten um 2000 Seeks/s – reproduzierbar, stabil und ohne signifikante CPU-Spitzen.
Das System blieb auch mit nur einer vCPU in der Dom0 reaktionsschnell und konstant. Keine Layer, keine Filter – nur direkter, effizienter Blockzugriff.
Bewertung: FFSv2 RAW liefert die beste Performance bei minimaler Komplexität.
VND und CCD – leichtgewichtig und effizient
VND-Images sind bequem, bringen aber messbaren Overhead, vor allem bei Random-Zugriffen. Für Test- oder Demo-Umgebungen brauchbar, für Performance-orientierte Setups eher zweite Wahl.
CCD (Concatenated Disk) dagegen überzeugte im Dauerbetrieb. Mehrere GPT-Partitionen lassen sich ohne Zusatzlayer zu einem zusammenhängenden Volume kombinieren. Der Durchsatz lag nur leicht unter FFS RAW, blieb aber stabil und planbar.
Bewertung: CCD ist die praktische Lösung für performante, erweiterbare Heimserver – nahe an RAW-Performance, aber flexibler.
Update: LVM in der Dom0 – stabiler als erwartet
In der ursprünglichen Version dieses Artikels wurde LVM bewusst nicht betrachtet. Hintergrund waren frühere Erfahrungen mit Inkompatibilitäten zwischen LVM, WAPBL und FSS-Snapshots, die zu System-Freezes und Instabilität führten.
Durch gezielte Nachtests konnte diese Annahme jedoch für eine klar abgegrenzte Architektur widerlegt werden:
- LVM wird ausschließlich in der Dom0 eingesetzt
- Die DomU erhält ein klassisches Blockdevice (Logical Volume)
- FFSv2, WAPBL und FSS-Snapshots laufen vollständig innerhalb der DomU
- Es findet keine Metadaten-Interaktion zwischen LVM und Dateisystem statt
Entscheidend ist die saubere Schichtung:
LVM kennt kein Dateisystem, WAPBL kennt kein LVM.
Unter diesen Bedingungen zeigten sich keine Stabilitätsprobleme – auch nicht bei aktiver Nutzung von FSS-Snapshots auf einem WAPBL-gesicherten FFSv2-Dateisystem.
LVM – Messergebnisse
Die Performance-Messungen erfolgten mit bonnie++ auf einem 32-GB-
Datensatz innerhalb der DomU:
- Write (Block): ~122 MB/s
- Read (Block): ~207 MB/s
- Random I/O: ~2000 Seeks/s
- CPU-Last: moderat, unauffällig
- Stabilität: reproduzierbar, keine Hänger
Der zusätzliche Mapping-Layer von LVM ist messbar, verändert das I/O-Verhalten jedoch nicht grundlegend. Insbesondere bei Random-I/O liegt LVM praktisch gleichauf mit FFSv2 RAW.
Bewertung: LVM bietet hohe Flexibilität bei überschaubarem Performance-Overhead und erweist sich in dieser Konstellation als produktive Option.
Messergebnisse im Vergleich
| Backend | Stabilität | Write (Block) | Read (Block) | Random (Seeks/s) | Einschätzung |
|---|---|---|---|---|---|
| ZVOL (ZFS) | instabil | 6–7 MB/s | 33–76 MB/s | 440–480 | Sehr hohe Latenzen |
| FFSv2 RAW | sehr gut | 147–151 MB/s | 254–260 MB/s | 2100–2300 | Beste Performance |
| VND (Imagefile) | gut | 144–145 MB/s | 129 MB/s | 1200–1300 | Leichter Overhead |
| CCD (Concatenated Disk) | sehr gut | 141–144 MB/s | 238–242 MB/s | 980–2200 | Stabil, erweiterbar |
| LVM (Logical Volume) | sehr gut | 122 MB/s | 207 MB/s | ~2000 | Flexibel, stabil |
Fazit
Die Tests zeigen klar: Performance entsteht durch Einfachheit. Auf minimaler Hardware bleibt FFSv2 RAW die Performance-Referenz, CCD der beste Kompromiss aus Durchsatz und Erweiterbarkeit.
Die ursprüngliche Annahme, dass LVM unter NetBSD grundsätzlich ungeeignet sei, hat sich in dieser Architektur nicht bestätigt. Wird LVM ausschließlich in der Dom0 eingesetzt und der DomU ein sauberes Blockdevice bereitgestellt, funktionieren FFSv2, WAPBL und FSS-Snapshots zuverlässig und reproduzierbar.
ZFS überfordert das System, VND bleibt eine Komfortlösung – LVM ergänzt die Palette nun als flexibelste Option mit moderatem Overhead.
Wer NetBSD/Xen performant betreiben will, sollte unnötige Layer vermeiden – aber saubere Abstraktionen dürfen existieren.
Überraschung: Zwei unscheinbare Klassiker – CCD und LVM – entpuppen sich als ernsthafte Alternativen zu modernen Storage-Stacks, wenn Einfachheit und klare Verantwortlichkeiten im Vordergrund stehen.
Bildnachweis: Das NetBSD-Logo ist eine eingetragene Marke der NetBSD Foundation, Inc. Verwendung im Rahmen redaktioneller Berichterstattung gemäß den Richtlinien zur Logonutzung.