Viele AIX Administratoren verwenden NFSv4 genauso wie zuvor NFSv3 und NFSv2. Beim Exportieren und Mounten wird die Version 4 angegeben, ansonsten wird alles wie bisher gemacht. Das funktioniert zwar in den meisten Fällen, verhindert aber gleichzeitig die Nutzung einiger interessanter Eigenschaften von NFSv4.
Der erste bedeutende Unterschied zwischen NFSv4 und seinen Vorgängern besteht schon beim Mounten. Bei NFSv2 und NFSv3 wird hierzu ein separates MOUNT-Protokoll verwendet. Soll beispielsweise der folgende NFS-Mount ausgeführt werden:
clientv3 # mount aixnim:/export/data /mnt clientv3 #
dann wird eine RPC-Anfrage and den rpc.mountd auf dem NFS-Server gesendet, um ein NFS-Filehandle für das Dateisystem/Verzeichnis /export/data zu bekommen. Bei allen NFS-Operationen muß immer ein NFS-Filehandle angegeben werden, welches auf dem NFS-Server eindeutig eine Datei oder Verzeichnis identifiziert. Das allererste Filehandle wird über das MOUNT-Protokoll erfragt.
Im Falle von NFSv4 sieht dies ganz anders aus, es wird kein separates MOUNT-Protokoll benötigt. Anstelle dessen wird ein sogenanntes root-Filehandle verwendet, dieses ist über den NFS-Standard definiert und muß nicht über ein separates Protokoll in Erfahrung gebracht werden. Bei dem folgenden NFSv4-Mount
clientv4 # mount –o vers=4 aixnim:/export/data /mnt clientv4 #
Startet der Client ein NFS-LOOKUP, wobei er das wohlbekannte (vom NFS-Standard definierte) root-Filehandle angibt, sowie den dazu relativen Pfad „export/data“, dann liefert der NFS-Server das zugehörige Filehandle zurück. Dies läßt sich mit Hilfe von tcpdump leicht verfolgen, was wir aus Platzgründen aber hier nicht getan haben.
Ein für viele Administratoren überraschender (und vielleicht nicht immer verstandener) Nebeneffekt ist, das man mit „showmount –e“ nicht die mit NFSv4 exportierten Filesysteme sehen kann. Das liegt aber einfach daran das es kein MOUNT-Protokoll für NFSv4 gibt. Damit kann man auf dem NFS-Client nicht so ohne weiteres herausfinden welche Filesysteme der NFS-Server für NFSv4 exportiert hat.
clientv4 # showmount -e aixnim no exported file systems for aixnim clientv4 #
Das Kommando „showmount –e“ zeigt keine exportierten Filesysteme, obwohl wir oben erfolgreich mittels NFSv4 mounten konnten. Wir kommen später noch einmal darauf zurück.
Der zweite bedeutende Unterschied ist das für NFSv4 der NFS-Server für jeden NFSv4 Client ein Pseudo-Filesystem erzeugt. Dieses Filesystem startet bei dem nfsroot-Verzeichnis (per Default ist das /) und beinhaltet alle darunter liegenden, für den Client exportierten, Verzeichnisse und Dateien. Das Pseudo-Filesystem wird auch dann erzeugt, wenn es für den Client kein exportiertes Filesystem gibt das er mounten könnte!
Zur Demonstration haben wir auf unserem NFS-Server aixnim keine exportieren Filesysteme zur Verfügung gestellt:
aixnim # lsnfsexp aixnim #
Obwohl für den NFS-Client noch nichts exportiert wurde, kann das für den Client generierte Pseudo-Filesystem trotzdem mittels NFSv4 gemountet werden:
clientv4 # mount -o vers=4 aixnim:/ /mnt clientv4 # ls -il /mnt total 0 clientv4 #
Das gemountete Filesystem ist natürlich leer, da ja noch nichts exportiert wurde. Wir hängen das gemountete Filesystem wieder aus (hier nicht gezeigt) und exportieren auf dem NFS-Server aixnim das Verzeichnis /var/adm:
aixnim # mknfsexp -d /var/adm -v 4 -r clientv4 aixnim # lsnfsexp /var/adm -vers=4,root=clientv4 aixnim #
Wir mounten nun erneut das Pseudo-Filesystem ab /:
clientv4 # mount -o vers=4 aixnim:/ /mnt clientv4 #
Um die Unterschiede zu NFSv2 und NFSv3 leichter illustrieren zu können, zeigen wir kurz noch das nützliche Kommando nfs4cl für den NFSv4-Client:
clientv4 # nfs4cl showfs Server Remote Path fsid Local Path -------- --------------- --------------- --------------- aixnim / 0:42949672964 /mnt clientv4 #
Das Kommando zeigt das von aixnim gemountete Pseudo-Filesystem /, das unter /mnt gemountet ist. Wir schauen nun kurz mit dem Kommando ls in das Verzeichnis /mnt
clientv4 # ls -il /mnt total 1 2 dr-xr-xr-x 2 root system 3 May 21 07:34 var clientv4 #
In dem vom NFS-Server generierten Pseudo-Filesystem ist nur die Pfad-Komponente /var sichtbar. Diese Pfad-Komponente ist ein Prefix des exportierten Verzeichnisses /var/adm. Andere Verzeichnisse wie /opt oder /usr sind im Pseudo-Filesystem nicht sichtbar, da diese nicht Prefix eines exportierten Pfades sind. Wir werfen einen Blick auf /mnt/var:
clientv4 # ls -il /mnt/var total 8 32 drwxrwxr-x 15 root adm 4096 May 2 11:30 adm clientv4 #
Auch unter var ist nur das Verzeichnis adm sichtbar, da nur /var/adm ein Prefix eines exportierten Pfades ist. Das Pseudo-Filesystem ist natürlich an den Stellen die nicht exportiert wurden unveränderbar, wie der Versuch eine Datei unter /mnt/var anzulegen zeigt:
clientv4 # touch /mnt/var/file touch: /mnt/var/file cannot create clientv4 #
Ab /mnt/var/adm sieht dann alles wie von NFSv2 und NFSv3 gewohnt aus, man hat Zugriff auf die exportierten Daten:
clientv4 # ls -il /mnt/var/adm total 704 110 drw-r----- 2 root system 256 May 20 14:33 SRC 4165 drwxrwxr-x 2 adm adm 256 Apr 17 08:07 acct 70 drwx------ 4 root system 256 Apr 17 07:50 config 4133 drwx------ 2 root system 256 Apr 17 08:03 corrals ... 4 33 -rw-rw-r-- 1 adm adm 337608 May 20 09:30 wtmp clientv4 #
Schauen wir uns jetzt noch einmal die Ausgabe des Kommandos “nfs4cl showfs” an:
Clientv4 # nfs4cl showfs Server Remote Path fsid Local Path -------- --------------- --------------- --------------- aixnim /var 0:42949672966 /mnt/var aixnim / 0:42949672964 /mnt clientv4 #
Für jedes physikalische Filesystem auf dem Server wird ein eigenes Pseudo-Filesystem erzeugt. Das jeweilige Pseudo-Filesystem gewährt Zugriff auf exportierte Verzeichnisse des unterliegenden physikalischen Filesystems und generiert für Pfad-Prefixe von exportierten Verzeichnissen read-only Verzeichnisse.
Wir exportieren auf dem NFS-Server aixnim noch das Verzeichnis /usr/share für den Client:
aixnim # mknfsexp -d /usr/share -v 4 -r clientv4 aixnim # lsnfsexp /var/adm -vers=4,root=clientv4 /usr/share -vers=4,root=clientv4 aixnim #
Auf dem Client führen wir dieses Mal keinen umount und erneuten Mount aus, sondern greifen mittels ls einfach noch einmal auf den Mountpunkt /mnt zu:
clientv4 # ls -il /mnt total 2 2 dr-xr-xr-x 2 root system 3 May 21 08:13 usr 2 dr-xr-xr-x 2 root system 3 May 21 07:34 var clientv4 #
Der Pfad-Prefix usr des gerade exportierte Verzeichnisses /usr/share taucht auf dem Client auf, ohne das wir explizit gemountet haben. Ein Blick nach /mnt/usr zeigt das wie erwartet das Verzeichnis share auftaucht:
clientv4 # ls -il /mnt/usr total 0 16390 drwxr-xr-x 8 bin bin 256 Apr 17 08:31 share clientv4 #
Und unter /mnt/usr/share befinden sich dann wie erwartet die exportierten Daten:
clientv4 # ls -il /mnt/usr/share total 24 74212 drwxr-xr-x 2 bin bin 256 Apr 17 08:24 X11 49162 drwxr-xr-x 2 bin bin 256 Nov 3 2015 dict 16391 drwxr-xr-x 12 bin bin 4096 Apr 17 08:22 lib 17762 lrwxrwxrwx 1 root system 26 Apr 17 08:31 locale -> /opt/freeware/share/locale 20653 drwxr-xr-x 5 root system 256 Apr 24 15:46 lpp 16911 drwxr-xr-x 11 bin bin 4096 May 20 14:25 man 45096 drwxr-xr-x 2 bin bin 4096 Apr 17 08:03 modems clientv4 #
Das Kommando „nfs4cl showfs“ zeigt nun 3 Filesysteme:
Clientv4 # nfs4cl showfs Server Remote Path fsid Local Path -------- --------------- --------------- --------------- aixnim /usr 0:42949672965 /mnt/usr aixnim /var 0:42949672966 /mnt/var aixnim / 0:42949672964 /mnt clientv4 #
Das letzte Beispiel zeigt das im Falle von NFSv4 neue Filesysteme nicht zwangsläufig manuell auf dem Client gemountet werden müssen. Werden weitere Filesysteme auf dem NFS-Server für einen NFSv4-Client exportiert, dann kann der Client einfach auf das neue Filesystem zugreifen. Voraussetzung ist allerdings das der Pfad für das neue Filesystem Bestandteil des vom Client gemounteten Pseudo-Filesystems ist. Da wir das komplette Pseudo-Filesystem ab dem nfsroot gemountet hatten, ist dies trivialerweise der Fall. Hätten wir aber lediglich /var vom NFS-Server gemountet, dann wäre /usr/share nicht Bestandteil des Pseudo-Filesystems von /var und es wäre ein separater Mount erforderlich gewesen.
Das weitere Filesysteme wie gerade gezeigt ohne explizites Mounten verfügbar sind, liegt in einem dritten Unterschied von NFSv4 zu seinen Vorgängern. Bei NFSv2 und NFSv3 sind alle Filehandle persistent, das heißt unveränderlich. Mit NFSv4 wurden volatile (zerbrechliche) Filehandle zusätzlich zu den persistent Filehandles eingeführt. Die vom Pseudo-Filesystem verwendeten Filehandle sind volatile. Das heißt der Client muß damit rechnen das sich ein solches Filehandle ändern kann. Dies ist der Fall wenn ein weiterer Pfad auf dem NFS-Server exportiert wurde, die Filehandles für die Pfad-Prefixe im Pseudo-Filesystem ändern sich dann, der Client bekommt dies nach kurzer Zeit mit und reagiert entsprechend.
Abschließend sei noch auf ein kleines Problem hingewiesen: wir hatten einen Mount durchgeführt, das Kommando „nfs4cl showfs“ hat allerdings gezeigt das hierbei zuletzt 3 Filesysteme beteiligt waren. Es ist aber nur ein Filesystem gemountet, wie df zeigt:
clientv4 # df -g Filesystem GB blocks Free %Used Iused %Iused Mounted on /dev/hd4 1.00 0.86 15% 8367 5% / /dev/hd2 6.12 2.90 53% 65563 9% /usr /dev/hd9var 2.00 1.81 10% 1770 1% /var /dev/hd3 2.00 1.89 6% 452 1% /tmp /dev/hd1 1.00 0.88 12% 454 1% /home /dev/hd11admin 0.50 0.50 1% 15 1% /admin /proc - - - - - /proc /dev/hd10opt 2.00 0.94 54% 22460 10% /opt /dev/livedump 1.00 1.00 1% 4 1% /var/adm/ras/livedump /dev/varadmloglv 2.00 1.85 8% 275 1% /var/adm/log aixnim:/ 0.38 0.20 47% 12644 22% /mnt clientv4 #
Das unter /mnt gemountete Filesystem ist 0.38 GB groß. Auf dem NFS-Server wurden /usr/share und /var/adm exportiert, ein df zeigt hier die folgenden Größen:
aixnim # df –g / /usr/share /var/adm Filesystem GB blocks Free %Used Iused %Iused Mounted on /dev/hd4 0.38 0.20 47% 12644 22% / /dev/hd2 2.06 0.23 89% 39236 41% /usr /dev/hd9var 0.50 0.45 10% 614 1% /var aixnim #
Offensichtlich werden beim Client die Werte des Filesystems / des NFS-Servers verwendet! Unter /usr und damit auch /usr/share wären noch knapp 2 GB verfügbarer Platz, was allerdings beim Kommando df auf dem Client nicht angezeigt wird. Es dürfte auch schwierig sein auf dem Client Werte anzugeben, da auf dem NFS-Server mehrere Filesysteme involviert sind. Das Kommando df zeigt hier einfach die Daten des dem gemounteten Pseudo-Filesystem unterliegenden physikalischen Filesystems an. In unserem Falle ist dies das root-Filesystem des NFS-Servers. Helfen kann hier wieder das Kommando nfs4cl, dieses besitzt ein Subkommando zum Anzeigen von Filesystem-Informationen ähnlich zu df:
clientv4 # nfs4cl showstat Filesystem 512-blocks Free %Used Iused %Iused Mounted on aixnim:/usr 4325376 482752 89% 39236 41% /mnt/usr aixnim:/var 1048576 947064 10% 614 1% /mnt/var aixnim:/ 786432 417944 47% 12644 22% /mnt clientv4 #
Dies ist identisch zu den Werten die bei df auf dem NFS-Server angezeigt werden.
Aber auch mit dem Standard-df von AIX kann man diese Information bekommen, wie die folgende Ausgabe zeigt:
clientv4 # df -g /mnt /mnt/usr /mnt/usr/share /mnt/var /mnt/var/adm Filesystem GB blocks Free %Used Iused %Iused Mounted on aixnim:/ 0.38 0.20 47% 12644 22% /mnt [NFSv4] 2.06 0.23 89% 39236 41% /mnt/usr [NFSv4] 2.06 0.23 89% 39236 41% /mnt/usr/share [NFSv4] 0.50 0.45 10% 614 1% /mnt/var [NFSv4] 0.50 0.45 10% 614 1% /mnt/var/adm clientv4 #
Es gibt natürlich noch eine Reihe weiterer Unterschiede, die aber hier nicht mehr angeschaut werden sollen. Vielleicht wird es noch einen weiteren Artikel zu dem Thema geben.
Nützlich sind die oben dargestellten Vorteile insbesondere bei hierarchischen Mounts. Bei NFSv4 muß man nur einen Mount durchführen und sich damit nicht mehr um die Reihenfolge der Mounts kümmern.
Das Verstehen der Funktionsweise des Pseudo-Filesystems für den NFSv4-Client hilft beim Ermitteln der exportierten Filesysteme auf dem Client. Anstelle „showmount -e“ wie bisher bei NFSv2 und NFSv3 zu benutzen (was bei NFSv4 kein Resultat erzielt), kann man einfach alles ab / mounten und dann mit cd und ls herausfinden was der NFS-Server exportiert hat.