If you search the Oracle Support website or the internet for information on Oracle’s direct NFS (dNFS), you’ll find a decent amount of useful information, including coded examples. However, if you look a little more closely, all of those examples show NFS v3.0 in use, and do not show examples using higher versions of NFS.
Oracle19c documentation states that Direct NFS Client supports NFSv3, NFSv4, NFSv4.1, and pNFS protocols to access the NFS server, but you have to search more deeply to learn that Oracle v11.2 supports only NFS v3.0, while v4.0, v4.1, and parallel NFS (pNFS) are supported from Oracle v12.1 and higher.
The same 19c documentation page also states that Direct NFS Client can obtain NFS mount points either from the operating system mount entries, or from the oranfstab
file, but it doesn’t state the important detail that obtaining NFS mount point information is available only with NFS v3.0, while the oranfstab
configuration file is required for higher versions of NFS. This is useful information that should be documented, but is not.
Using dNFS with all versions of NFS requires running the command make -f ins_rdbms.mk dnfs_on
in the $ORACLE_HOME/rdbms/lib
subdirectory, as well as ensuring that the oradism
executable in the $ORACLE_HOME/bin
subdirectory has is owned by root
and has SETUID file permissions.
But creating an oranfstab
configuration file is only optional with NFS v3.0; the dNFS client can obtain information about NFS mount points from the standard UNIX/Linux /etc/mtab
file. However, for NFS v4.x, it is required to create the oranfstab
file, either in the global /etc
directory or in the installation-specific $ORACLE_HOME/dbs
subdirectory.
Documentation for the contents of the oranfstab
file is found HERE, but there is another important detail that is not included in the documentation: the ordering of the attributes, listed as name/value pairs, matters.
For example, if the contents of the oranfstab file looks like this, with the properties ordered as follows, then all works well…
server: anfv41 local: 10.0.0.4 path: 10.1.0.4 export: /ora-anfv41-vol01 mount: /u02 nfs_version: NFSv4.1 security_default: sys
However if, for example, the path
and local
properties were specified in reversed order, then dNFS does not work properly…
server: anfv41 path: 10.1.0.4 local: 10.0.0.4 export: /ora-anfv41-vol01 mount: /u02 nfs_version: NFSv4.1 security_default: sys
The server
attribute must always be specified first as the “header” of the following attributes describing a specific mount-point. Of course, the oranfstab
file can contain information about multiple mount points, each of which is initiated by the server
attribute.
The local
attribute must come next, followed by the path
attribute. The export
and mount
attributes must be on the same line, following path
. I have tried different variations of ordering for the nfs_version
and security_default
attributes with no adverse effect, but it seems logical to specify them last, and the order they are specified doesn’t seem to matter.
As you can imagine, this behavior can easily lead to insidious problems. When dNFS is misconfigured, the result is not that dNFS is disabled, but rather that dNFS is enabled but far from optimally. In general, performance is abysmal, resulting in cases I’ve observed where a database startup which normally completes in seconds taking upwards of 30 minutes, effectively rendering the database unusable.
In summary, upgrading from NFS v3.0 to NFS v4.1 is a good thing to do today, especially for the improvements in security (i.e. encryption, authentication, parallel NFS, etc), as well as the improvements in stability (i.e. integrated locking with leases, etc) and simplicity (i.e. more firewall-friendly by using fewer ports, etc).
Best of all, even though Oracle is light on documentation for higher versions of NFS, you don’t have to abandon Oracle’s direct NFS (dNFS) while taking advantages of the improvements offered by NFS v4.1.
But it would be nice if Oracle documented all of this more coherently.