[NFS] [Cluster-devel] [PATCH 0/4 Revised] NLM - lock failover
Wendy Cheng
wcheng at redhat.com
Sat Apr 28 03:55:27 UTC 2007
Frank van Maarseveen wrote:
>I'm quite interested in _any_ patch which would allow me to drop
>the locks obtained by NFS clients on a specific export, either by (1)
>"exportfs -uh" or by (2) "echo /some/path > /proc/fs/nfsd/nlm_drop_lock"
>as Neil mentioned.
>
>
Thanks for commenting on this. Opinions from users who will eventually
use these interfaces are always valued.
>[snip]
>
>
>I'd prefer (2) "echo /some/path > /proc/fs/nfsd/nlm_drop_lock" because:
>
>
To convert the first patch of this submitted series from "fsid" to
"/some/path" is a no-brainer, since we had gone thru several rounds of
similar changes. However, my questions (it is more of a Neil's question)
are, if I convert the first patch to do this,
1) then why do we still need the RPC drop-lock call in nfs-util ?
2) what should we do for the 2nd patch ? i.e., how do we communicate
with the take-over server it is time for its action, by RPC call or by
"echo /some/path > /proc/fs/nfsd/nlm_set_grace_or_whatever" ?
In general, I feel if we do this "/some/path" approach, we may as well
simply convert the 2nd patch from "fsid" to "/some/path". Then we would
finish this long journey.
-- Wendy
>- Tying the -h (drop locks) option to -u (unexport) is too restrictive IMO.
> For one thing, there's a bug in the linux NFS client locking code (I
> reported this earlier) which results in locks not being removed from
> the server. It was not too difficult to reproduce and programs on the
> client will wait forever due to this. To handle these kind of situations
> I need (2) on the server.
>
>- (2) may be useful for other NFS server setups: it is inherently more
> flexible.
>
>- (2) does not depend on nfs-utils. It's simpler.
>
>
>(*) virtual in this case means a UUID or IP based fsid= option and an
>additional IP address on eth0 per export entry, such, that it becomes
>possible to move an export entry + disk partition + local mount to
>different hardware without needing to remount it on all <large number>
>NFS clients.
>
>
>
More information about the Cluster-devel
mailing list