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.
