NFS-Ganesha vs. Kernel-NFSd: Was in TrueNAS wann Sinn ergibt

NFS ist im Enterprise-Storage die unauffällige Konstante: seit Jahrzehnten im Einsatz, verstanden von jeder Plattform, langweilig im besten Sinne. Trotzdem stehen Administratoren in TrueNAS-Umgebungen regelmäßig vor der Frage, ob der klassische Kernel-NFSd die richtige Wahl ist oder ob NFS-Ganesha im User-Space die bessere Antwort liefert. Wir zeigen, worin sich beide unterscheiden, wo die Grenzen verlaufen und wann sich ein Wechsel wirklich lohnt.

Zwei Architekturen, ein Protokoll

Der Kernel-NFSd (nfsd) ist Teil des Linux- bzw. FreeBSD-Kernels. Er teilt sich Adressraum, Caches und I/O-Pfad mit dem Dateisystem und hat entsprechend kurze Wege: Ein NFS-Request landet über den Netzwerkstack im Kernel, wird vom NFS-Server verarbeitet und direkt an ZFS weitergereicht. Kein Context-Switch, kein Umkopieren zwischen Kernel- und User-Space.

NFS-Ganesha dagegen ist ein vollständiger NFS-Server im User-Space. Er sitzt oberhalb des Kernels und spricht mit dem Dateisystem über sogenannte FSAL-Module (File System Abstraction Layer). Das klingt zunächst nach Nachteil - jeder I/O-Pfad muss zusätzliche Schichten durchlaufen. In der Praxis ergeben sich daraus aber Fähigkeiten, die der Kernel-NFSd nicht bietet.

Kriterium	Kernel-NFSd	NFS-Ganesha
Laufzeitumgebung	Kernel-Space	User-Space
Backend-Anbindung	Direkt an VFS/ZFS	FSAL-Module (ZFS, GlusterFS, Ceph, VFS)
pNFS-Unterstützung	Eingeschränkt	Voll, inkl. Flex-Files
NFSv4.2-Features	Grundlagen	Umfassend inkl. Server-Side Copy
Debugging	dtrace, kdb, aufwendig	gdb, Logs im User-Space
Restart-Verhalten	Meist Reboot nötig	Prozess-Neustart im laufenden Betrieb
Rohdurchsatz auf 10GbE	Sehr hoch, kurze Pfade	Etwas höher CPU-Overhead
Cluster-Fähigkeit	Nicht vorgesehen	Aktiv genutzt (CTDB, Ceph)

TrueNAS SCALE nutzt standardmäßig den Kernel-NFSd, TrueNAS CORE ebenfalls (FreeBSD-Variante). Ganesha ist in beiden Editionen nicht Teil der Default-Installation, lässt sich aber auf SCALE-Basis in Custom-Deployments einsetzen - typischerweise in Kombination mit Cluster-Storage oder speziellen Compliance-Anforderungen.

Wo der Kernel-NFSd gewinnt

Für die große Mehrheit klassischer Workloads ist der Kernel-NFSd die richtige Wahl. Er ist ausgereift, gut instrumentiert und in TrueNAS ohne Zusatzaufwand einsatzbereit. Konkret spielt er seine Stärken hier aus:

• Roher Durchsatz auf 10/25/100 GbE. Ohne Context-Switch zwischen Kernel und User-Space kann der NFSd Line-Rate ausreizen, sofern ZFS mitspielt. Für VM-Datastores unter Proxmox oder ESXi ist das der entscheidende Faktor.
• Niedrige Latenz bei kleinen I/Os. Metadaten-lastige Workloads wie Home-Directories, Git-Repos oder CI-Runner profitieren vom kurzen Pfad.
• Wartungsarme Betriebsführung. Der NFSd ist Teil des Systems - Updates kommen über die regulären TrueNAS-Releases, kein separater Paket-Stack.
• Bekanntes Debugging-Toolset. nfsstat, rpcinfo, dtrace oder bpftrace liefern belastbare Metriken direkt am Kernel-Pfad.

Wer eine TrueNAS-Umgebung primär als NFS-Datastore für Virtualisierung betreibt, sollte diesen Pfad ohne Not nicht verlassen. Auch die enge Kopplung an ZFS - inklusive korrekter Behandlung von sync=always, ZIL/SLOG und ARC - ist im Kernel besser abgedeckt als in jeder User-Space-Implementierung.

Wo Ganesha seine Trumpfkarten ausspielt

Interessant wird Ganesha, sobald Anforderungen ins Spiel kommen, die der Kernel-NFSd nicht oder nur eingeschränkt bedient. Drei Szenarien tauchen in unserer Beratung besonders häufig auf:

1. pNFS mit Flex-Files. Parallel-NFS verteilt Datenzugriffe direkt zwischen Client und mehreren Data-Servern - der Metadaten-Server bleibt aus dem Datenpfad heraus. Für HPC-Cluster oder Video-Rendering-Farmen kann das die effektive Bandbreite deutlich erhöhen, weil ein einzelner NFS-Server nicht mehr der Flaschenhals ist. Der Linux-Kernel unterstützt pNFS heute clientseitig sehr gut, serverseitig ist Ganesha jedoch die deutlich vollständigere Implementierung.
2. Cluster-Storage. Ganesha ist die Referenz-Implementierung für NFS über CephFS und GlusterFS. Wer TrueNAS ergänzend zu einem Ceph-Cluster einsetzt oder eine Migration plant, kommt an Ganesha kaum vorbei.
3. Feingranulare Kontrolle und Debuggability. Ganesha lässt sich pro Export mit unterschiedlichen FSALs, Log-Leveln und Security-Flavors konfigurieren, ohne dass ein Kernel-Reboot fällig wird. Für Umgebungen mit hoher Änderungsfrequenz - etwa Multi-Tenant-Storage - ist das ein spürbarer Vorteil.

Ein oft unterschätzter Punkt: Ganesha kann bei Bedarf einzelne Exports isolieren. Ein Fehlverhalten in einem Export-Modul reißt nicht den gesamten NFS-Server mit, wie es beim Kernel-NFSd im Extremfall passieren kann. Für Umgebungen, in denen NFS eine SLA-relevante Rolle spielt, ist diese Isolation ein hartes Argument.

Was das für TrueNAS bedeutet

TrueNAS ist bewusst opinionated: Storage-Appliance, kein Baukasten. Der Default ist der Kernel-NFSd, und iX Systems investiert seine Engineering-Ressourcen genau dort. Wir halten das für die richtige Entscheidung - für 95 Prozent der Fälle liefert der Kernel-Pfad exakt das, was Kunden brauchen.

Die restlichen fünf Prozent sind es aber, in denen die Frage nach Ganesha aufkommt. In unserer Praxis begegnen uns typischerweise diese Muster:

• Migration von einem Ceph- oder Gluster-Cluster hin zu TrueNAS - hier wird Ganesha vorübergehend als Bridge genutzt.
• HPC-Setups mit pNFS-Anspruch, in denen ein einzelner Namespace über mehrere TrueNAS-Nodes verteilt werden soll. Das ist kein TrueNAS-Kernfeature und erfordert Custom-Engineering.
• Regulierte Umgebungen, in denen jeder Export ein separates Audit-Log und eigene Kerberos-Realms braucht.

In allen drei Fällen empfehlen wir, Ganesha nicht auf der TrueNAS-Appliance selbst zu betreiben, sondern auf einer separaten Linux-VM oder einem dedizierten Node, der TrueNAS als Backend-Storage nutzt. Damit bleibt die Support-Fähigkeit der Appliance erhalten und die Verantwortung für den User-Space-Server liegt klar beim Betriebsteam.

Konfigurationsbeispiel auf 10GbE

Wir zeigen typische Konfigurationen für beide Varianten. Ausgangslage: TrueNAS SCALE mit einem Mirror-Pool aus NVMe-Devices, dediziertem SLOG und 10-GbE-Anbindung an einen Proxmox-Cluster.

Für den Kernel-NFSd reicht in TrueNAS SCALE die UI - im Hintergrund werden die Exports in /etc/exports.d/ gepflegt. Wichtig sind aus unserer Erfahrung diese Parameter:

# Auszug /etc/exports.d/tank-vmstore.exports
/mnt/tank/vmstore \
    10.20.30.0/24(rw,sync,no_subtree_check,no_root_squash,\
                  sec=sys,fsid=42,mountpoint)

Dazu gehört eine passende ZFS-Konfiguration:

zfs set sync=always tank/vmstore
zfs set recordsize=64K tank/vmstore   # fuer VM-Images
zfs set atime=off tank/vmstore
zfs set compression=lz4 tank/vmstore

sync=always ist bei VM-Datastores nicht verhandelbar - hier muss ein SLOG mit Power-Loss-Protection her, sonst leidet die Latenz massiv. Wir haben das im Detail in unseren Beratungsprojekten rund um Proxmox immer wieder gesehen.

Für Ganesha auf einer separaten Linux-VM sieht die Konfiguration deutlich reichhaltiger aus:

# /etc/ganesha/ganesha.conf (Auszug)
NFS_CORE_PARAM {
    Protocols = 3,4;
    NSM_Use_Caller_Name = true;
}

EXPORT {
    Export_Id = 42;
    Path = /mnt/tank/vmstore;
    Pseudo = /vmstore;
    Access_Type = RW;
    Squash = No_Root_Squash;
    SecType = sys, krb5, krb5i, krb5p;
    FSAL {
        Name = VFS;
    }
    CLIENT {
        Clients = 10.20.30.0/24;
        Access_Type = RW;
    }
}

LOG {
    Default_Log_Level = EVENT;
    Components {
        FSAL = INFO;
        NFS4 = DEBUG;
    }
}

Der Wert liegt hier in der Granularität: Pro Export lässt sich der Log-Level anpassen, ein Kerberos-Realm zuweisen oder ein anderes FSAL-Modul einbinden. Ein systemctl reload nfs-ganesha übernimmt die Änderungen ohne Downtime - ein Feature, das der Kernel-NFSd in dieser Form nicht bietet.

Wichtiger Hinweis zu Benchmarks: Wir veröffentlichen keine Zahlen, die wir nicht in einer sauber dokumentierten Testumgebung selbst reproduziert haben. Herstellerangaben zu Durchsatz und Latenz variieren stark nach Workload, Client-Version und ZFS-Tuning. Wer belastbare Zahlen für die eigene Umgebung braucht, sollte mit fio gegen einen realen Client testen - idealerweise mit dem tatsächlichen Workload-Profil, nicht mit synthetischen 4K-Random-Reads.

Wie wechseln - und wann besser nicht

Ein Wechsel vom Kernel-NFSd auf Ganesha ist keine reine Konfigurationsaufgabe. Wir empfehlen folgende Reihenfolge:

• Bedarfsanalyse: Welche Ganesha-Fähigkeit ist der eigentliche Treiber? pNFS, Cluster, Multi-Tenant-Kontrolle? Ohne klaren Grund lohnt der Aufwand nicht.
• Isolierter Aufbau: Ganesha auf einer separaten Linux-VM oder einem Bare-Metal-Node aufsetzen, TrueNAS als Backend anbinden. Nie parallel zum Kernel-NFSd auf derselben Appliance.
• Client-Migration: NFS-Mounts schrittweise umziehen, idealerweise über eine neue Export-Pseudo-Root-Struktur. Der Rollback bleibt so jederzeit möglich.
• Monitoring: ganesha_stats und nfsstat auf beiden Seiten aktiv halten, um Regressionsverdacht schnell zu erhärten oder auszuräumen.

Wer diese Punkte nicht sauber abarbeitet, riskiert eine schleichende Verschlechterung - erst fällt die Latenz auf, dann tauchen Locking-Probleme auf, am Ende wird die Migration teurer als ein sauberes Redesign gewesen wäre.

Fazit

Der Kernel-NFSd bleibt für die meisten TrueNAS-Deployments die richtige Wahl: schnell, unaufgeregt, gut unterstützt. NFS-Ganesha ist kein Ersatz, sondern eine Ergänzung für Szenarien, in denen pNFS, Cluster-Storage oder feingranulare Kontrolle den Ausschlag geben. Die Entscheidung sollte nie aus Bauchgefühl, sondern immer aus einer konkreten Anforderung heraus fallen.

DATAZONE unterstützt Sie bei der Auswahl der passenden NFS-Architektur, beim TrueNAS-Design und bei der Integration in bestehende Proxmox- oder VMware-Umgebungen. Sprechen Sie uns an - unser Kontakt ist der schnellste Weg zu einer belastbaren Einschätzung für Ihre Umgebung.