Re: NFS Serving Issues
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Colin Simpson wrote:
,when the service is stopped I get a "Stale NFS file handle" from mounted filesystems accessing the NFS mount point at those times. i.e. if I have a copy going I get on the service being disabled:
That's normal if a NFS server mount is unexported or nfsd shuts down. It _should_ (but doesn't always) clear when NFS resumes.The only way around this is to define an IP for the NFS service/export pair and make the IP the final dependency in the service (ie, the IP is the last thing to come up and first thing to go down):
<service autostart="1" domain="msslap-pref" name="MSSLAU-X41" recovery="restart">
<clusterfs ref="/stage/peace12"> <nfsexport ref="msslau-x41-exports"><nfsclient ref="/stage/peace12--@alphac"> <nfsclient ref="/stage/peace12--127/8"> <nfsclient ref="/stage/peace12--@linuxt">
<nfsclient ref="/stage/peace12--@plasmawriter"> <nfsclient ref="/stage/peace12--@webserver"> <ip ref="192.168.128.41"/> </nfsclient> </nfsclient> </nfsclient> </nfsclient> </nfsclient> </nfsexport> </clusterfs> </service>
The above format of cluster.conf having the "ip ref" contain the rest of the things is as per the "Deploying Highly Available NFS on Red Hat Enterprise Linux 6" document.
But if I don't enclose the nfs and fs things in the ip, the clients hang until the services restart i.e
Which is normal NFS client behaviour. (Cluster sends out a bunch of gratuitous ARPs when the services change host in order to have the IP/arp pair updated more quickly.)
BTW Is it best practice to use one nfsexport per nfsclient or is one nfsexport resource enough cluster wide?
"It depends" If all NFS will come off one host then one resource is enough. If NFS might run off several hosts then you'll need one resource per export.
Why is there a behaviour disparity? Which is correct?
They're both correct - and both wrong. :)
Question 2: I have the old case on either of the above where I can't unmount the exported file system when I stop the service (so I can't migrate it). Not unless I halt the file server hosting the file share or force fence it. I just get the old: # umount /mnt/home umount: /mnt/home: device is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1))
On client side, umount -l will help in these cases.on server side, restarting the nfslock service is usually sufficent to get umount to work (It's safe, clients are told to reacquire their locks)
Of course nothing is shown in lsof or fuser. This is annoying for a number of reasons. One is that I can't readily perform basic load balancing by migrating NFS services to their correct nodes (as I can'tmigrate a service without halting a node).
What's your backend? GFS?
But more seriously I can't easily shut the cluster down cleanly when told to by a UPS on power outage. Shutting down the node will be unable to be performed cleanly as a resource is open (so will be liable to fencing).
If the filesystem is GFS, fencing is about the only reliable way of leaving the cluster.
However: if you shut down nfsd _and_ nfslock, you should be able to unmount the FSes cleanly.
-- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster