SIOS TECHNOLOGY CORP.

NFS Server – Known Issues / Restrictions

Description
NFS v4 and bind mounts cannot be used together on systems where /etc/mtab is a symlink to /proc/self/mounts

Bind mounts cannot be used with NFS v4 shares on these systems (RHEL 7.0 and later, CentOS 7.0 and later, OEL 7.0 and later, and SLES 12 SP1 and later) because the bind information that was formerly found in /etc/mtab is not found in /proc/self/mounts.
Top level NFS resource hierarchy uses the switchback type of the hanfs resource

The switchback type, which dictates whether the NFS resource hierarchy will automatically switch back to the primary server when it comes back into service after a failure, is defined by the hanfs resource.
Some clients are unable to reacquire nfs file locks

When acting as NFS clients, some Linux kernels do not respond correctly to notifications from an NFS server that an NFS lock has been dropped and needs to be reacquired. As a result, when these systems are the clients of an NFS file share that is protected by LifeKeeper, the NFS locks held by these clients are lost during a failover or switchover.


When using storage applications with locking and following recommendations for the NFS mount options, SPS requires the additional nolock option be set, e.g. rw,nolock,bg,hard,nointr,tcp,nfsvers=3,timeo=600,rsize=32768,wsize=32768,actimeo=0.

(Revised in Oct 2021）
File lock switchover during resources switchover/failover does not work.
Do not use file lock from client applications.
NFS v4 cannot be configured with IPv6

IPv6 virtual IP gets rolled up into the NFSv4 heirarchy.


Solution: Do not use an IPv6 virtual IP resource when creating an NFSv4 resource.
NFS v4: Unable to re-extend hierarchy after unextend

Extend fails because export point is already exported on the target server. A re-extend to server A of a NFS v4 hierarchy will fail if a hierarchy is created on server A and extended to server B, brought in service on server B and then unextended from server A.


Solution: On server A run the command “exportfs -ra“ to clean up the extra export information left behind.
File Lock switchover with NFSv3 fails on some operating systems

Failover file locks with NFSv3 during resources switchover/failover does not work on the operating systems listed below. Lock failover with NFSv3 is currently not supported on these OS versions.
  • RHEL8, CentOS8, OL8

  • RHEL7, CentOS7, OL7

  • SLES15

  • SLES12

Solution: Use the lock failover features available with NFSv4.

(Revised in Oct 2021）
File lock switchover during resources switchover/failover does not work. File lock switchover with NFS v4 does not work regardless of the operating system.
Do not use file lock from client applications.
The Oracle Recovery Kit does not support NFSv4

The Oracle Recovery Kit supports NFSv3 for shared database storage. NFSv4 is not supported at this time due to NFSv4 file locking mechanisms.
Stopping and starting NFS subsystem adversely impacts SIOS Protection Suite protected NFS exports.

If the NFS subsystem is stopped while SIOS Protection Suite for Linux is protecting NFS exports, then all SIOS Protection Suite for Linux protected exported directories will be impacted as the NFS stop action performs an unexport of all the directories. The SIOS Protection Suite for Linux NFS quickCheck script will detect the stopped NFS processes and the unexported directories and run a local recovery to restart the processes and re-export the directories. However, it will take a quickCheck run for each protected export for the SIOS Protection Suite NFS ARK to recover everything. For example, if five exports are protected by the SIOS Protection Suite for Linux NFS ARK, it will take five quickCheck runs to recover all the exported directories the kit protects. Based on the default quickCheck time of two minutes, it could take up to ten minutes to recover all the exported directories.


Workaround: Do not stop the NFS subsystem while the SIOS Protection Suite NFS ARK is actively protecting exported directories on the system. If the NFS subsystem must be stopped, all NFS resources should be switched to the standby node before stopping the NFS subsystem. Use of the exportfs command should also be considered. This command line utility provides the ability to export and unexport a single directory thus bypassing the need to stop the entire NFS subsystem.
For servers with UDP disabled, such as RHEL8, you need to configure “NFS_RPC_PROTOCOL=tcp” in /etc/default/LifeKeeper

UDP is used for nfsd startup verification. Resource creation will fail on servers with UDP disabled. Changes are required to verify startup with TCP.

Feedback

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment