Search the docs

NFS

Hammerspace provides data access over NFS to a broad set of client operating systems, including Linux, Windows, UNIX, and macOS.

NFSv4.2 has only been tested with Linux clients. More information about which distributions are tested is available in the Hammerspace 5.2 Hardware and Software Compatibility List.

NFSv4 Client Unique-Id Requirement

The NFSv4 protocol (applies to both 4.1 and 4.2) requires each client to have a unique ID. By default, the Linux NFS client uses an ID string that contains the local node name. Therefore, if all node names are unique, no further action is required. Failure to use unique IDs on nodes will result in unreliable NFSv4 operations.

If node names are not unique, the following steps can be used to assign a unique NFSv4 id:

  1. Execute the following command:

    # umount -a -t nfs; modprobe -r nfs; mount -a -t nfs

  2. Reboot the client or execute the following command. (This assumes all current NFS mounts are defined in /etc/fstab.)

    # echo "options nfs nfs4_unique_id=`uuidgen`" >> /etc/modprobe.d/local.conf

For more details, refer to https://www.kernel.org/doc/Documentation/filesystems/nfs/nfs.txt.

NFS Version-Specific Mount Examples

If you are not familiar with NFS mount options, read the NFS man page for the client operating system. Here are a few examples that will work for most Linux clients:

NFSv4.2 example:

# mount -t nfs -o vers=4.2 <DSX DATA IP>:<EXPORT PATH> <MOUNT POINT>

NFSv4.1 example:

# mount -t nfs -o vers=4.1,nolock <DSX DATA IP>:<EXPORT PATH> <MOUNT POINT>

NFSv3 example:

# mount -t nfs -o vers=3,nolock <DSX DATA IP>:<EXPORT PATH> <MOUNT POINT>

Supported NFS Protocols

NFS version Status

Version 3

Supported

Version 4.1

Supported
[IMPORTANT] When NFS 4.1 support is enabled, NFS 4.2 clients must mount the shares from the Anvil and not the DSX nodes.

Version 4.2

  • Supported by qualified clients. See the Hammerspace Hardware and Software Compatibility List for specifics. If a client tries to access and it is not on the qualified list, it will transparently be re-directed to NFSv3 protocol version, and the mount will succeed.

  • NFS 4.2 clients must have network access to all storage volumes where data may be stored.

  • For RHEL 7.x & CentOS 7.x clients, make sure the client flexfiles timeout is adjusted due to an incorrect default value.

  • Add the following single line to /etc/modprobe.d/hs_flex.conf and reboot the client:

    options nfs_layout_flexfiles dataserver_retrans=0 dataserver_timeo=600

  • Mount kernel check bypass option:

    For NFS clients that cannot mount due to the kernel output not matching the approved list, there is a way to bypass the strict kernel check. It is recommended to only use this option when the kernel is 5.15 or later. Note that the bypass option is only supported when mounting against the Anvil IP. Example:

    mount -t nfs -o vers=4.2,port=20492 <ANVIL IP>:<EXPORT PATH> <MOUNT POINT>

Enabling NFS LOCALIO on Linux Clients

You can enable the LOCALIO auxiliary RPC protocol on RHEL10 or any other kernel that has LOCALIO support enabled. To do this, add a file to /etc/modprobe.d/, e.g. /etc/modprobe.d/localio.conf with the following text:

Enabling LOCALIO in localio.conf
options nfs localio_enabled=Y

_[Or add]_

"nfs.localio_enabled=Y" to the kernel cmdline, e.g.:

grubby --args=nfs.localio_enabled=Y --update-kernel /boot/vmlinuz-6.12-678.el10.x86_64

Whenever a client connects over NFSv4.2 to protod, and protod does not have a cached entry for it, protod will initiate an EXCHANGE_ID request to a potential server on the client. If the client accepts the request and replies, it will send back the so_major_id in the reply.

See the following example on Doxie:

Doxie EXCHANGE_ID example
doxie2 ~ $ hs-server-owner-list

566369: 0x2807446442C6FC0F: MAIN: protod_config_file_read:4104 Reading config from /pd/fs/protod.conf - this will overwrite default values.

Volume ID Client ID Owner ID

337 6 "doxie-dsx1.lab.hammer.space"

395 9 "doxie-dsx2.lab.hammer.space"

421 11 "doxie-dsx3.lab.hammer.space"

477 18 "doxie-dsx5.lab.hammer.space"

482 138 "doxie-dsx4.lab.hammer.space"

502 20 "doxie-dsx6.lab.hammer.space"

Each of the following clients would be considered to have local IO to doxie-dsx6.ba.hammer.space:

Example showing clients with LOCALIO enabled
doxie2 ~ $ hs-client-owner-list | grep dsx6

567854: 0x6394451709575D65: MA,IN: protod_config_file_read:4104 Reading c /pd/fs/protod.conf - this will overwrite default values.

165 "Linux NFSv4.2 21d1ba73-b292-48b8-bfbf-e37ead97eb8d/doxie-dsx6.lab.hammer.space"

140 "Linux NFSv4.2 cc8011c0-ab65-4df1-8576-8ab97291ea01/doxie-dsx6.lab.hammer.space"

19 "Linux NFSv4.2 doxie-dsx6.lab.hammer.space"

166 "Linux NFSv4.2 21d1ba73-b292-48b8-bfbf-e37ead97eb8d/doxie-dsx6.lab.hammer.space"

139 "Linux NFSv4.2 cc8011c0-ab65-4df1-8576-8ab97291ea01/doxie-dsx6.lab.hammer.space"

20 "Linux NFSv4.2 doxie-dsx6.lab.hammer.space"
Not shown in the example above is that 19 and 20 probably correspond to the port 20491 and 20492 connections for case-sensitive and case-insensitive mounts.

Then, for each client that connects, protod scans the list of server owners, and if the so_major_id is a substring at the end of the co_ownerid, the client is considered to have localized storage.

The following sections describe how to set up the NFSv4 server and client identifiers on a Tier 0 architecture so that protod can discover the co-location of the client and data server.

To configure the NFSv4 client owner on Linux, refer to the following article: https://docs.kernel.org/filesystems/nfs/client-identifier.html.

Based on the Linux kernel documentation and implementation details, the Linux NFSv4 server likely constructs the server owner name (also called "server scope") using the system’s hostname by default.