The following describes known problems with the NFS Toolkit
and workarounds for them. However, this is subject to change without
notice. For the most current information contact your HP support representative.
More recent information on known problems and workarounds
may be available on the Hewlett Packard IT Resource Center:
http://itrc.hp.com (Americas and Asia Pacific)
http://europe.itrc.hp.com (Europe)
JAGaf57739:
HA NFS and ‘Stale NFS Handle |
 |
What is the problem?
Serviceguard relies on LVM to manage its shared storage containing data
and files of applications managed by SG. Just as with other applications,
an NFS instance managed by SG means that the specific instance is “active” on
one node at a time, with all resources available to that node only
(including volume groups configured as a resource for the NFS package).
If the package goes down on node 1, the resources are released
so that the second node can “claim” the resources.
The package is brought up, and the instance is now “active” on
node 2. NFS clients continue to connect to the server, unaware that
the server has migrated from one node to another.
Behavior has changed in Linux kernel 2.6 such that the kernel
uses lvm2 with the device mapper to virtualize devices instead of
using the actual physical names. In this implementation, the actual
device node for a logical volume is dynamically created upon vg
activation, meaning a vg that starts out on node 1 but is failed
over to node 2 can very easily end up with a different minor number
after fail over. This will result in clients who connected before
the failover getting a “stale NFS handle”. The
volume groups are created with dynamic minor numbers. This causes
NFS problems (‘stale nfs handle’) on the client
when the NFS package is migrated to another node
What is the workaround? There are two
ways to address this issue:
Create
the logical volumes with persistent minor numbers.
Export the filesystem with
an assigned filesystem identification.
|
| |
|
 | NOTE: Refer to the README File for more detailed information. |
|
| |
|
A new configuration file called hanfs.conf has been introduced in this version, which provides
the choice of monitoring the rpc.rquotad daemon (which is an optional daemon).
JAGag06739:
Serviceguard/LX NFS server returns ESTALE when package is brought
down |
|
What is the problem? When the NFS package
is brought down, the client process gets ESTALE from the server
while it should not. There is a delay when the interface is brought
down and that package could still reach the NFS server layer.
This is due to exportfs -u, and the ESTALE is returned. When an interface is brought
down, the routes do not get flushed immediately. Therefore, the
server keeps temporarily responding for after shutting down the
interface.
What is the workaround?
Do the following steps on all the nodes that are configured
for running NFS package to set min_delay to zero while the system
is running:
Run the command
#
echo 0 > /proc/sys/net/ipv4/route/min_delay
Add the following line in /etc/sysctl.conf (in order to have persistent min_delay value across
server boots) net.ipv4.route.min_delay = 0.
Printable version
