Many AIX administrators use NFSv4 in the same way as NFSv3 and NFSv2 before. When exporting and mounting version 4 is specified, otherwise everything else is done as before. While this works in most cases, it also prevents the use of some interesting features of NFSv4.
The first significant difference between NFSv4 and its predecessors already shows up when mounting. NFSv2 and NFSv3 use a separate MOUNT protocol. For example, to run the following NFS mount:
clientv3 # mount aixnim:/export/data /mnt
clientv3 #
an RPC request is sent to the rpc.mountd on the NFS server to get an NFS filehandle for the file system/directory /export/data. All NFS operations must always specify an NFS filehandle that uniquely identifies a file or directory on the NFS server. The very first filehandle is requested via the MOUNT protocol.
In the case of NFSv4 this looks quite different, no separate MOUNT protocol is needed. Instead, a so-called root filehandle is used, which is defined by the NFS standard and need not be learned through a separate protocol. At the following NFSv4 mount
clientv4 # mount –o vers=4 aixnim:/export/data /mnt
clientv4 #
the client starts an NFS LOOKUP specifying the well-known (NFS default) root filehandle and relative path “export/data“, then the NFS server returns the associated filehandle. This can easily be tracked with the help of tcpdump, which we did not do here for reasons of space.
A side effect that is surprising for many administrators (and maybe not always understood) is that you can not see the filesystems exported with NFSv4 with “showmount -e“. This is simply because there is no MOUNT protocol for NFSv4. So you can not easily find out on the NFS client which file systems the NFS server has exported for NFSv4.
clientv4 # showmount -e aixnim
no exported file systems for aixnim
clientv4 #
The command “showmount -e” does not show exported file systems, although we were able to mount successfully using NFSv4. We’ll come back to that later.
The second significant difference is that for NFSv4 the NFS server generates a pseudo-file system for each NFSv4 client. This file system starts with the nfsroot directory (by default this is /) and contains all underlying directories and files exported to the client. The pseudo-file system is also created if there is no exported file system for the client!
For demonstration purposes, we have un-exported all file systems on our NFS server aixnim:
aixnim # lsnfsexp
aixnim #
Although nothing has been exported yet for the NFS client, the per client-generated pseudo-file system can be mounted using NFSv4:
clientv4 # mount -o vers=4 aixnim:/ /mnt
clientv4 # ls -il /mnt
total 0
clientv4 #
The mounted file system is of course empty, since nothing has been exported yet. We unmount the mounted file system again (not shown here) and export the directory /var/adm on the NFS server aixnim:
aixnim # mknfsexp -d /var/adm -v 4 -r clientv4
aixnim # lsnfsexp
/var/adm -vers=4,root=clientv4
aixnim #
We now mount the pseudo-file system / again:
clientv4 # mount -o vers=4 aixnim:/ /mnt
clientv4 #
In order to illustrate the differences to NFSv2 and NFSv3 more easily, we briefly show the useful command nfs4cl for the NFSv4 client:
clientv4 # nfs4cl showfs
Server Remote Path fsid Local Path
-------- --------------- --------------- ---------------
aixnim / 0:42949672964 /mnt
clientv4 #
The command shows the pseudo-file system / from aixnim, which is mounted under /mnt. We now look briefly with the command ls in the directory /mnt
clientv4 # ls -il /mnt
total 1
2 dr-xr-xr-x 2 root system 3 May 21 07:34 var
clientv4 #
In the pseudo-file system generated by the NFS server, only the path component /var is visible. This path component is a prefix of the exported directory /var/adm. Other directories such as /opt or /usr are not visible in the pseudo-file system, because they are not prefixes of an exported path. We take a look at /mnt/var:
clientv4 # ls -il /mnt/var
total 8
32 drwxrwxr-x 15 root adm 4096 May 2 11:30 adm
clientv4 #
Also under directory var, only the directory adm is visible, since only /var/adm is a prefix of an exported path. The pseudo-file system is of course unchangeable at the places that were not exported, as the attempt to create a file under /mnt/var shows:
clientv4 # touch /mnt/var/file
touch: /mnt/var/file cannot create
clientv4 #
Starting with /mnt/var/adm everything looks like we know from NFSv2 and NFSv3, one has access to the exported data:
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 #
Now let’s look again at the output of the command “nfs4cl showfs“:
Clientv4 # nfs4cl showfs
Server Remote Path fsid Local Path
-------- --------------- --------------- ---------------
aixnim /var 0:42949672966 /mnt/var
aixnim / 0:42949672964 /mnt
clientv4 #
For each physical file system on the server, a separate pseudo-file system is created. The respective pseudo-file system grants access to exported directories of the underlying physical file system and generates read-only directories for path prefixes of exported directories.
On the NFS server aixnim we export the directory /usr/share for the 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 #
On the client this time we do not umount and re-mount, but simply use ls to access the mount point /mnt again:
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 #
The path prefix usr of the currently exported directory /usr/share appears on the client without having explicitly performed a mount. A look at /mnt/usr shows that the directory share appears as expected:
clientv4 # ls -il /mnt/usr
total 0
16390 drwxr-xr-x 8 bin bin 256 Apr 17 08:31 share
clientv4 #
And under /mnt/usr/share are, as expected, the exported data:
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 #
The command “nfs4cl showfs” now shows 3 file systems:
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 #
The last example shows that in the case of NFSv4 new file systems do not necessarily have to be manually mounted on the client. If further file systems are exported on the NFS server for an NFSv4 client, the client can simply access the new file system. Prerequisite, however, is that the path for the new file system is part of the client-mounted pseudo-file system. Since we had the entire pseudo-file system starting from the nfsroot mounted, this is trivially the case. But if we had only mounted /var from the NFS server, then /usr/share would not be part of the pseudo-file system of /var and a separate mount would have been necessary.
That additional file systems can be accessed without explicit mount, as just shown, comes from a third difference of NFSv4 to its predecessors. For NFSv2 and NFSv3, all filehandles are persistent, that is, immutable. NFSv4 introduced volatile filehandles in addition to persistent filehandles. The file handles used by the pseudo-file system are volatile. That means the client must expect that such a filehandle can change. This is the case if another path is exported on the NFS server, the filehandles for the path prefixes in the pseudo-file system change then, the client recognizes this after a short time and responds accordingly.
Finally, a small problem should be noted: we had 1 mount done, but the command “nfs4cl showfs” showed that 3 filesystems were involved. But there is only one file system mounted, as df shows:
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 #
The file system mounted under /mnt is 0.38 GB in size. On the NFS server, /usr/share and /var/adm were exported, a df shows the following sizes:
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 #
Obviously, the values of the file system / of the NFS server are used on the client! Under /usr and thus also /usr/share would be available free space of close to 2 GB, but this is not reflected in the df output on the client. Of course it is difficult to specify values on the client, because multiple file systems are involved on the NFS server. The df command simply displays the data of the physical file system underlying the mounted pseudo-file system. In our case, this is the root file system of the NFS server. Here again you can use the command nfs4cl, which has a subcommand for displaying file system information similar to 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 #
This is identical to the values displayed by df on the NFS server.
But even with the standard df of AIX you can get this information, as the following output shows:
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 #
Of course there are a number of other differences of NFSv4 and previous versions, but they should not be discussed here. Maybe there will be another article on the subject.
The features presented above are especially useful for hierarchical mounts. With NFSv4, you only need to mount one filesystem and you need not worry about the order of mounts.
Understanding how the pseudo-file system works for the NFSv4 client helps determine the exported file systems on the client. Instead of using “showmount -e” as before with NFSv2 and NFSv3 (which does not get results with NFSv4), you can simply mount everything starting with / and then use cd and ls to find out what the NFS server has exported.
