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

NFS ist im Enterprise-Storage die unauffaellige Konstante: seit Jahrzehnten im Einsatz, verstanden von jeder Plattform, langweilig im besten Sinne. Trotzdem stehen Administratoren in TrueNAS-Umgebungen regelmaessig 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 ueber 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 vollstaendiger NFS-Server im User-Space. Er sitzt oberhalb des Kernels und spricht mit dem Dateisystem ueber sogenannte FSAL-Module (File System Abstraction Layer). Das klingt zunaechst nach Nachteil - jeder I/O-Pfad muss zusaetzliche Schichten durchlaufen. In der Praxis ergeben sich daraus aber Faehigkeiten, 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-Unterstuetzung	Eingeschraenkt	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 noetig	Prozess-Neustart im laufenden Betrieb
Rohdurchsatz auf 10GbE	Sehr hoch, kurze Pfade	Etwas hoeher CPU-Overhead
Cluster-Faehigkeit	Nicht vorgesehen	Aktiv genutzt (CTDB, Ceph)

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

Wo der Kernel-NFSd gewinnt

Fuer die grosse 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 Staerken 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. Fuer 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 Betriebsfuehrung. Der NFSd ist Teil des Systems - Updates kommen ueber die regulaeren 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 primaer als NFS-Datastore fuer 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 eingeschraenkt bedient. Drei Szenarien tauchen in unserer Beratung besonders haeufig 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. Fuer HPC-Cluster oder Video-Rendering-Farmen kann das die effektive Bandbreite deutlich erhoehen, weil ein einzelner NFS-Server nicht mehr der Flaschenhals ist. Der Linux-Kernel unterstuetzt pNFS heute clientseitig sehr gut, serverseitig ist Ganesha jedoch die deutlich vollstaendigere Implementierung.
2. Cluster-Storage. Ganesha ist die Referenz-Implementierung fuer NFS ueber CephFS und GlusterFS. Wer TrueNAS ergaenzend zu einem Ceph-Cluster einsetzt oder eine Migration plant, kommt an Ganesha kaum vorbei.
3. Feingranulare Kontrolle und Debuggability. Ganesha laesst sich pro Export mit unterschiedlichen FSALs, Log-Leveln und Security-Flavors konfigurieren, ohne dass ein Kernel-Reboot faellig wird. Fuer Umgebungen mit hoher Aenderungsfrequenz - etwa Multi-Tenant-Storage - ist das ein spuerbarer Vorteil.

Ein oft unterschaetzter Punkt: Ganesha kann bei Bedarf einzelne Exports isolieren. Ein Fehlverhalten in einem Export-Modul reisst nicht den gesamten NFS-Server mit, wie es beim Kernel-NFSd im Extremfall passieren kann. Fuer Umgebungen, in denen NFS eine SLA-relevante Rolle spielt, ist diese Isolation ein hartes Argument.

Was das fuer 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 fuer die richtige Entscheidung - fuer 95 Prozent der Faelle liefert der Kernel-Pfad exakt das, was Kunden brauchen.

Die restlichen fuenf 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 voruebergehend als Bridge genutzt.
• HPC-Setups mit pNFS-Anspruch, in denen ein einzelner Namespace ueber 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 Faellen 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-Faehigkeit der Appliance erhalten und die Verantwortung fuer den User-Space-Server liegt klar beim Betriebsteam.

Konfigurationsbeispiel auf 10GbE

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

Fuer 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 gehoert 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.

Fuer 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 Granularitaet: Pro Export laesst sich der Log-Level anpassen, ein Kerberos-Realm zuweisen oder ein anderes FSAL-Modul einbinden. Ein systemctl reload nfs-ganesha uebernimmt die Aenderungen ohne Downtime - ein Feature, das der Kernel-NFSd in dieser Form nicht bietet.

Wichtiger Hinweis zu Benchmarks: Wir veroeffentlichen 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 fuer die eigene Umgebung braucht, sollte mit fio gegen einen realen Client testen - idealerweise mit dem tatsaechlichen 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-Faehigkeit 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 ueber eine neue Export-Pseudo-Root-Struktur. Der Rollback bleibt so jederzeit moeglich.
• Monitoring: ganesha_stats und nfsstat auf beiden Seiten aktiv halten, um Regressionsverdacht schnell zu erhaerten oder auszuraeumen.

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

Fazit

Der Kernel-NFSd bleibt fuer die meisten TrueNAS-Deployments die richtige Wahl: schnell, unaufgeregt, gut unterstuetzt. NFS-Ganesha ist kein Ersatz, sondern eine Ergaenzung fuer Szenarien, in denen pNFS, Cluster-Storage oder feingranulare Kontrolle den Ausschlag geben. Die Entscheidung sollte nie aus Bauchgefuehl, sondern immer aus einer konkreten Anforderung heraus fallen.

DATAZONE unterstuetzt 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 Einschaetzung fuer Ihre Umgebung.