[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [NFS] [Cluster-devel] [PATCH 0/4 Revised] NLM - lock failover



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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]