Der Linux Kernel-NFS-Daemon

Vorwort

Die NFS-Implementierung von Linux hatte in Kernel 2.0 zahlreiche Probleme. Um sie einmal kurz (nicht unbedingt vollständig) aufzuzählen: NFSv3 ist noch nicht implementiert, NFS über TCP funktioniert nicht, die Interoperabilität mit anderen Unices ist schlecht, und die Performance insbesondere beim Schreiben unbefriedigend.

Seit dem Entwicklerkernel 2.1 gibt es neben dem bisherigen NFS-Daemon, der als normaler Prozeß implementiert ist, einen NFS-Daemon im Kernel. Wenig ist über diesen bekannt. Einerseits ist er noch in Entwicklung, d.h. er hat teilweise noch die gleichen Probleme wie der alte NFS-Daemon, zum anderen ist es schwierig, Dokumentation über ihn zu finden. Ich habe nach Durchforsten aller einschlägigen Quellen nichts gefunden. Wenn jemand eine Dokumentation kennt, möge er mir bitte Bescheid sagen!

Mangels Dokumentation habe ich mir alles, was im folgenden beschrieben ist, aus Hintergrundwissen, Manpages und Inspektion des /proc-Dateisystems zusammengereimt. Ein Wunder, daß es geklappt hat ;-)

Dieser Artikel ist nur für Leser gedacht, die sich bereits mit NFS auskennen und im günstigsten Fall bereits NFS laufen haben oder hatten. Wer hier nach NFS-Grundlagen sucht, sucht an der falschen Stelle.

Installation

Ich ging das Risiko ein, den Daemon zu testen. Als Kernel verwendete ich 2.2.14, gepatcht mit den neuesten IDE-Treibern und Reiserfs. Obwohl es auch Patches für den NFS-Daemon gibt, verzichtete ich auf diese zunächst.

Zuerst braucht man einen Kernel mit dem NFS-Daemon. Dazu ruft man make menuconfig oder make xconfig auf und wählt unter File systemsNetwork file systems den nfsd aus. Die Option mit der Sun-Kompatibilität habe ich weggelassen. Dann erzeugt und installiert man den Kernel wie immer.

Nach dem Reboot mit dem neuen Kernel stoppt man zunächst den alten NFS-Daemon:

/etc/rc.d/nfsd stop

Dieses Kommando ist je nach Distribution unterschiedlich.

Jetzt können wir schon den Kernel-NFS-Daemon starten:

modprobe nfsd

Statt einer Fanfare und Tusch passiert jetzt aber gar nichts. Es gibt auch nichts, was man an diesem Kernel-Modul einstellen könnte. Was uns fehlt, um den Dämonen zu wecken, sind die NFS-Utilities, enthalten in nfs-utils-0.14.tar.gz. Diese sind vom Linux NFS Project herunterzuladen.

OK, entpacken wir dieses Paket und installieren es mit dem bekannten Dreisatz:

./configure
make
make install

Ein Wort der Warnung: Dies überschreibt den alten NFS-Daemon und alle Tools. Der einzige Weg zurück ist daher die Neuinstallation des alten NFS-Daemons.

Nun können wir das Setup vervollständigen. Unter der Annahme, daß der Portmapper (rpc.portmap bzw. portmap) bereits läuft und die Datei /etc/exports konfiguriert ist, können wir eingeben:

rpc.mountd
rpc.nfsd
exportfs -a

Nun müßte ein mount von einem anderen Rechner aus gelingen.

Performance und Einschränkungen

Der Kernel-NFS-Daemon sollte schneller sein als der alte Daemon. Also führte ich ein paar Messungen durch. Der Server ist ein Dual Celeron-466 mit schneller IDE-Platte und zwei Netzwerkkarten (10 und 100 Mbit/s). Als Clients kamen Linux 2.x auf diversen PCs und IRIX 5.3 auf SGI Indy zum Einsatz. Hier sind meine Befunde:

CPU	Netz	theoret. Maximum	Lesen	Schreiben
Linux 2.3.35	P-233	100 Mbit/s	12.5 MB/s	3.27 MB/s	3.64 MB/s
Linux 2.2.3	P-200	100 Mbit/s	12.5 MB/s	2.80 MB/s	4.46 MB/s
Linux 2.2.14	P-133	10 Mbit/s	1.25 MB/s	0.18 MB/s	0.59 MB/s
Linux 2.0.36	Celeron-333	10 Mbit/s	1.25 MB/s	0.39 MB/s	0.28 MB/s
IRIX 5.3	R4000-100	10 Mbit/s	1.25 MB/s	0.26 MB/s	0.26 MB/s

Zum Vergleich der gleiche Test mit dem alten NFS-Server:

CPU	Netz	theoret. Maximum	Lesen	Schreiben
Linux 2.3.35	P-233	100 Mbit/s	12.5 MB/s	3.13 MB/s	2.98 MB/s
Linux 2.2.3	P-200	100 Mbit/s	12.5 MB/s	3.46 MB/s	4.76 MB/s
Linux 2.2.14	P-133	10 Mbit/s	1.25 MB/s	0.14 MB/s	0.60 MB/s
Linux 2.0.36	Celeron-333	10 Mbit/s	1.25 MB/s	0.37 MB/s	0.27 MB/s
IRIX 5.3	R4000-100	10 Mbit/s	1.25 MB/s	0.27 MB/s	0.26 MB/s

Für diesen Test wurde nicht die Option rsize=8192,wsize=8192 eingesetzt, die eigentlich die Performance erhöhen sollte (außer auf der Indy, wo das der Default ist). Es sieht jedoch so aus, als ob rsize keinen nennenswerten Einfluß hat, während ein großer Wert von wsize das Ganze wesentlich verlangsamt. Allerdings bestand der Test nur aus dem Kopieren einer Datei von exakt 4 MB (bei 10 Mbit/s) bzw. 16 MB (bei 100 Mbit/s), so daß hier keine allgemeingültigen Aussagen möglich sind.

Im Vergleich mit dem alten NFS-Server sind die Ergebnisse fast die gleichen, manchmal niedriger, manchmal höher. Bei diesem Test gab es auch keine NFS-Fehler, wie man sie beim alten NFS-Daemon leider des öfteren beobachten kann.

Da jeder Test nur einmal durchgeführt wurde, können die Zahlen nur als Anhaltspunkte dienen. insgesamt ist die Performance schon nicht schlecht, aber noch verbesserungswürdig. Interessant ist der Ausreißer bei Linux 2.2.14. Für diesen gibt es eigentlich keine Erklärung. Zwar ist der Rechner ein Laptop mit PCMCIA-Netzwerkkarte und der Kernel ist nicht das echte 2.2.14, sondern pre11, aber dennoch sind die Zahlen erstaunlich.

Alle Tests liefen ohne Fehlermeldung ab. Somit kann ich subjektiv sagen, daß die Stabilität des neuen Daemons besser ist als die des alten. Denn dort war es z.B. erst gar nicht möglich, von IRIX aus etwas zu schreiben - die Geschwindigkeit lag nahe bei 0, und der NFS-Daemon hatte erhebliche Aussetzer.

Es gibt also gute Gründe, den Kernel-NFS-Daemon einzusetzen, doch ist Vorsicht geboten, denn er ist noch im Betastadium. Das merkt man auch an der einen oder anderen Stelle. Mit dem alten NFS-Daemon war es z.B. möglich, ein leeres Verzeichnis zu exportieren, dann beispielsweise eine CD dort zu mounten, und sofort konnten alle Clients auf die CD zugreifen. Mit dem neuen Daemon wird nur eine Fehlermeldung im Log erzeugt. Abhilfe schafft das Stoppen und Neustarten des Daemons, doch ist das sicher ein Punkt, der noch korrigiert werden muß.

Es ist zu hoffen, daß Linux 2.4 eine weniger verpfuschte NFS-Implementierung mitbringt, denn NFS ist enorm wichtig. Das weiß jeder, der einmal zwei UNIX-Rechner vernetzt hat.