Besonderheiten von NFSv4 Mounts

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.

 

%d Bloggern gefällt das: