On Wed, Jun 02, 2010 at 08:59:01AM +0200, Florian Haas wrote: > On 06/01/2010 11:33 AM, RaSca wrote: > > Il giorno Mar 01 Giu 2010 08:27:31 CET, Andrew Beekhof ha scritto: > > [...] > >> Who is in charge of stopping/detaching nfsd? exportfs perhaps? > >> The solution is to get that part working, until it does the cluster wont > >> work. > > > > exportfs actually does not have the capability of doing anything on the > > running nfsd. It should be modified by adding nfsd handle. > > > > So, this resource agent at this moment is totally useless, because it > > does not handle any of the tasks described. > > That is incorrect. It does handle everything it is supposed to handle, > but it appears that exportfs (the binary) isn't doing what its man page > says it does: exportfs -u is supposed to "shut down all NFS activity" on > the export affected. Which to me would mean that the NFS daemon would > also relinquish any open server-side NFS file handles. Apparently, at > least for your system, it doesn't. > > > I patched the script to do a nfsd restart, based upon what the RA > > nfsserver do. In this way, things works, but seems a little bit ugly... > > I'm going to do some tests and then post the patch. > > That is intrusive; it affects _all_ exports, not just the one this > exportfs resource is managing. As such it isn't any better than nfsserver. > > We have been discussing this on the list for several weeks now, and are > still looking for the best way to fix this. This is also the reason why > exportfs isn't part of any resource-agents release yet. > > Lars (Ellenberg), could you comment on this please?
Typically "references" from NFS to the underlying file system even after "unexport" come from file locks. To verify that, try mounting from the clients with nolock. If you cannot do without locks, figure out how to convince nfs to drop the references corresponding to those locks. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. _______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
