Skip to content

NLM - lock failover

Wendy Cheng cluster-devel linux-nfs 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 Latest0 of 4 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 4 patches the cover letter announces are in this archive.

Reviews trailers per patch

No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.

Read the v1 thread

Cover letter [NFS] [Cluster-devel] [PATCH 0/4 Revised] NLM - lock failover
Quoted 6 lines · Frank van Maarseveen

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.

Quoted 6 lines

[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

Quoted 10 lines

- 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.

Quoted 11 lines

- (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.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs