NLM failover unlock
Subsystems (2)
cover NLM failover unlock
This submission is part of the patch sets added to support NFS server failover where the specified export is moved from one physical server to another. The technical discussions can be found at cluster-devel mailing list archives:
https://www.redhat.com/archives/cluster-devel/2007-April/msg00028.html
The implementation has not changed much since first RFC. The external interfaces, however, have been revised several times. During latest code review, it was suggested using export path name as the interface. The idea was subsequently prototyped but found difficult to implement. The killing issue is the existing lockd reclaim code structure on backup server. The associated export path name is difficult to retrieve (based on client svc_rqst structure) when the reclaim call is invoked. The details is explained in:
[1] http://people.redhat.com/wcheng/Patches/NFS/NLM/004.txt
Nevertheless, as commented by few IT folks who are current managing NFS servers on daily basis, the lock dropping feature itself is useful, regardless failover and/or cluster setup. This new patch set allows system administrator (or cluster user mode applications) to drop NLM lock on server based on any one of the following two criteria:
o Server in-bound IP address
o Export path name (with restriction - see above [1] for details)
The reclaiming grace period can only be set based on server in-bound IP address and the associated patch set will be submitted after this patch set is settled and accepted.
-- Wendy
Quoted 1 line · Wendy Cheng
This submission is part of the patch sets added to support NFS server failover where the specified export is moved from one physical server to another.
Wendy,
What's the current status of these patches? I believe I have a situation that could benefit from being able to release all NLM locks on an exported filesystem.
Signature · 1 line
Bob Bell
A message that is not in the archive (sent off-list or not yet received): 20080214183833.GA26936-y89O8yXFYpDSsb2jM9SCN5/[email protected]
Quoted 7 lines · Bob Bell
Quoted 1 line · Wendy Cheng
This submission is part of the patch sets added to support NFS server failover where the specified export is moved from one physical server to another.
Wendy,
What's the current status of these patches? I believe I have a situation that could benefit from being able to release all NLM locks on an exported filesystem.
I think Bruce has queued the unlock patch for 2.6.26 (Bruce ?) ..
-- Wendy
Quoted 6 lines · Wendy Cheng
Quoted 5 lines · Bob Bell
Quoted 3 lines · Wendy Cheng
This submission is part of the patch sets added to support NFS server failover where the specified export is moved from one physical server to another.
Quoted 7 lines
Quoted 6 lines
Wendy,
What's the current status of these patches? I believe I have a situation that could benefit from being able to release all NLM locks on an exported filesystem.
I think Bruce has queued the unlock patch for 2.6.26 (Bruce ?) ..
Not yet, for several reasons. First, there's two smaller problems outstanding that I can recall:
- We should be matching on the superblock, not the vfs mount. Otherwise, for example, the unlock will have no effect if it's done from a private namespace, which I think will be unexpected. Arguably this could result in revoking more locks than necessary, but if the goal is to allow unmounting some shared block device, then that's what we've got to do.
- Let's get the address types right. I think the concensus from previous discussions was just to use in6_addr everywhere?
(Both those should be relatively small-let me know if you can resend fixed versions or if you'd like me to fix them up--either's fine.)
As I've said before I'd also like to see how this will fit into a solution for some longer-term problems:
- How will we block locks on other nodes of a cluster filesystem during grace periods/failover?
- How will the comparable v4 references to the filesystem (from opens and locks) be revoked?
I'm working on those (some patches are in
git://linux-nfs.org/~bfields/linux.git failover
but it's still at an early stage.) But I don't want the perfect to be the enemy of the good, so, sure, if it looks like that's not going to be figured out by 2.6.26 then I'll queue up this unlock patch before then.
We do need at least the small problems above fixed, though.
Also, are you planning to address the comments on the grace period patches, or do you want me to take over revising them?
--b.
Quoted 18 lines · J. Bruce Fields
Quoted 6 lines · Wendy Cheng
Quoted 5 lines · Bob Bell
Quoted 3 lines · Wendy Cheng
This submission is part of the patch sets added to support NFS server failover where the specified export is moved from one physical server to another.
Quoted 7 lines
Quoted 6 lines
Wendy,
What's the current status of these patches? I believe I have a situation that could benefit from being able to release all NLM locks on an exported filesystem.
I think Bruce has queued the unlock patch for 2.6.26 (Bruce ?) ..
Not yet, for several reasons. First, there's two smaller problems outstanding that I can recall:
Quoted 8 lines
- We should be matching on the superblock, not the vfs mount. Otherwise, for example, the unlock will have no effect if it's done from a private namespace, which I think will be unexpected. Arguably this could result in revoking more locks than necessary, but if the goal is to allow unmounting some shared block device, then that's what we've got to do.
- Let's get the address types right. I think the concensus from previous discussions was just to usein6_addreverywhere?
I thought the consensus was use in_addr everywhere, and let me worry about converting these to in6_addr as part of the NLM IPv6 work.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
Quoted 31 lines · Chuck Lever
Quoted 21 lines · J. Bruce Fields
Quoted 8 lines · Wendy Cheng
Quoted 7 lines · Bob Bell
Quoted 5 lines · Wendy Cheng
This submission is part of the patch sets added to support NFS server
failover where the specified export is moved from one physical server
to another.Quoted 8 lines
Quoted 7 lines
Wendy,
What's the current status of these patches? I believe I have a situation that could benefit from being able to release all NLM locks
on an exported filesystem.I think Bruce has queued the unlock patch for 2.6.26 (Bruce ?) ..
Not yet, for several reasons. First, there's two smaller problems outstanding that I can recall:
Quoted 8 lines
- We should be matching on the superblock, not the vfs mount. Otherwise, for example, the unlock will have no effect if it's done from a private namespace, which I think will be unexpected. Arguably this could result in revoking more locks than necessary, but if the goal is to allow unmounting some shared block device, then that's what we've got to do.
- Let's get the address types right. I think the concensus from previous discussions was just to usein6_addreverywhere?
Quoted 2 lines
I thought the consensus was use
in_addreverywhere, and let me worry about converting these toin6_addras part of the NLM IPv6 work.
OK, that'd be fine too.
--b.
Quoted 3 lines · J. Bruce Fields
Also, are you planning to address the comments on the grace period patches, or do you want me to take over revising them
You're welcome to take over the revising tasks !
-- Wendy