1. „RAIDZ eignet sich hervorragend für Virtualisierung.“ RAIDZ ist ein kapazitätsoptimiertes Layout, kein Performance-Layout. Zwar bietet RAIDZ2 oder Z3 hervorragende Schutzmechanismen, doch die Struktur führt dazu, dass die IOPS-Leistung stets von einer einzelnen Platte limitiert wird. Für sequentielle Workloads mag das akzeptabel sein – für Virtualisierung ist es katastrophal. Vor allem Random-IO, wie sie bei VMs ständig entsteht, verlangt nach parallelen I/O-Kanälen. Die bekommt man nur mit Mirror-VDEVs oder NVMe-Spiegeln. Wer VMs auf RAIDZ betreibt, wird irgendwann zwangsläufig über schwankende Latenzen und mangelnde Performance klagen. 2. „L2ARC macht das System generell schneller.“ Ein verbreiteter Irrtum. L2ARC ist kein Allheilmittel und ersetzt keinen fehlenden RAM. Er ist eine Ergänzung, keine Beschleunigerkarte. In vielen Fällen wird er falsch eingesetzt – besonders dann, wenn kaum RAM für Metadaten zur Verfügung steht. Erst wenn das Working Set größer als der ARC ist, der Workload überwiegend leseintensiv ist und die Architektur ausreichend RAM bietet, kann L2ARC etwas bringen. Für die meisten KMU-Umgebungen ist zusätzlicher RAM fast immer sinnvoller und nachhaltiger. 3. „Dedup spart automatisch viel Speicherplatz.“ Dedup fasziniert – technisch ist es beeindruckend, praktisch jedoch eine der teuersten Funktionen, die ZFS bietet. Der Grund liegt in der großen DDT (Dedup-Tabelle), die gewaltige Mengen RAM beanspruchen kann. In vielen Realwelt-Umgebungen, besonders in heterogenen VM-Landschaften oder Dateiablagen, ergeben sich kaum nennenswerte Einsparungen. Dedup lohnt sich nur in sehr spezifischen Einsatzszenarien – zum Beispiel bei großen, hochgradig redundanten VDI-Pools. Für klassische KMU-Workloads bleibt es meist eine Fehlkonfiguration. 4. „Die volblocksize kann man später anpassen.“ Nein – sobald ein ZVOL erstellt wurde, ist die Blockgröße fix. Dieser Parameter beeinflusst Performance und Effizienz massiv. Besonders bei VMs ist eine falsche Blockgröße ein häufiger Grund für schlechte Latenzen. Die beste Wahl für VM-Speicher bleibt weiterhin: 16K. Es ist ein robustes, universelles Layout, das gut mit den meisten Hypervisoren harmoniert und konsistent arbeitet. 5. „NFS ist grundsätzlich langsamer als iSCSI.“ Das mag früher gestimmt haben – heute aber kaum noch. Moderne Implementierungen wie NFSv4.2, nconnect und entsprechende NIC-Offloading-Optimierungen erlauben es, NFS auf das gleiche Niveau wie iSCSI zu bringen. Der Unterschied ist heute weniger technischer Natur, sondern hängt vom gewünschten Verhalten ab: iSCSI ist strikter strukturiert, während NFS mehr Flexibilität bietet. „NFS ist langsam“ ist fast immer das Ergebnis schlechter Konfigurationen – nicht des Protokolls. 6. „ZFS profitiert kaum von mehr CPU-Kernen.“ ZFS ist ein ausgesprochen paralleles Dateisystem. Es arbeitet intern mit vielen Threads, die Prüfsummen, Kompression, Snapshots, ARC-Berechnung und Scrubs parallel verarbeiten können. Mehr CPU-Kerne sorgen dafür, dass diese Prozesse nicht zu Engpässen werden. Gerade bei ZSTD-Kompression oder sehr großen ARC-Caches zeigen zusätzliche Kerne einen deutlich messbaren Effekt. 7. „NVMe beschleunigt immer das gesamte System.“ NVMe ist schnell – aber nur, wenn es im passenden Layout betrieben wird. Eine NVMe-RAIDZ-Gruppe bleibt trotz schneller Medien durch die RAIDZ-Struktur limitiert. NVMe entfaltet sein Potenzial erst dann, wenn es in Mirror-Konfigurationen genutzt wird. Dort liefert es niedrige Latenzen und sehr hohe IOPS – ideal für Virtualisierung und datenintensive Dienste. Falsch eingesetzt wird es jedoch lediglich zu einer sehr teuren Kapazitätslösung. 8. „Ein SLOG beschleunigt jede Art von Storage-Workload.“ SLOG beschleunigt ausschließlich synchrone Schreibvorgänge. Das betrifft z. B. bestimmte VM-Workloads (je nach Hypervisor-Einstellung), Datenbanken oder NFS mit sync=always. Für klassische SMB-Freigaben oder Backup-Ziele bringt ein SLOG dagegen keine Veränderung. Im Gegenteil: ein falsch dimensioniertes oder ungespiegeltes SLOG kann zum Risiko werden. Wer SLOG nutzt, sollte es ausschließlich auf schnellen, stromausfallsicheren SSDs (mit Power-Loss Protection) platzieren – und immer als Mirror. 9. „Snapshots beeinträchtigen die Performance deutlich.“ Bei ZFS ist ein Snapshot kein schweres Abbild wie bei herkömmlichen Filesystemen, sondern ein einfacher Verweis auf bestehende Metadaten. Das bedeutet: Snapshots sind leichtgewichtig, erzeugen kaum Overhead und kosten praktisch keine IOPS. Erst wenn tausende Snapshots in einem einzigen Dataset existieren, können Verwaltungslasten spürbar werden. Für normale KMU-Umgebungen ist das irrelevant. 10. „Mehr RAM lohnt sich nur für große Systeme.“ Das Gegenteil ist der Fall. RAM ist der wichtigste Performancefaktor für ZFS, weil der ARC nahezu alle wiederkehrenden Operationen beschleunigt. Mehr RAM verbessert: Caching Metadatenzugriffe Snapshots Read-Performance Kompressionseffizienz Die Faustregel gilt weiterhin: ZFS liebt RAM – und es gibt kaum ein Zu viel. Vergleichstabelle: Was die meisten Mythen gemeinsam haben Mythos Ursache in der Praxis Was ZFS wirklich tut RAIDZ für VMs sei schnell falsches RAID-Denken ZFS braucht parallelisierte VDEVs NFS sei langsam alte Versionen / falsche Config modern → leistungsstark L2ARC beschleunigt alles Missverständnis über ARC nur sinnvoll + RAM-intensiv Snapshots kosten IOPS Vergleich mit klassischen NAS ZFS-COW → nahezu kein Overhead Dedup spart Platz falsche Erwartungshaltung nur für Spezialfälle geeignet Fazit Viele Performanceprobleme in TrueNAS entstehen nicht durch mangelnde Hardware, sondern durch falsche Erwartungen aus einer anderen Storage-Generation. ZFS hat seine eigenen Regeln – und wer diese versteht, baut Systeme, die stabiler und performanter sind als herkömmliche Lösungen. Wir analysieren eure bestehende Umgebung, identifizieren Engpässe und entwickeln ein optimiertes ZFS-Layout – exakt zugeschnitten auf eure Workloads. Jetzt Termin vereinbaren
