[PATCH 0/2] NLM failover unlock

[PATCH 0/2] NLM failover unlock

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

Re: [PATCH 0/2] NLM failover unlock

[Bob Bell]

On Mon, Jan 07, 2008 at 12:31:09AM -0500, Wendy Cheng wrote:
>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.

-- 
Bob Bell

Re: [PATCH 0/2] NLM failover unlock

[Wendy Cheng]

Bob Bell wrote:
> On Mon, Jan 07, 2008 at 12:31:09AM -0500, Wendy Cheng wrote:
>> 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

Re: [PATCH 0/2] NLM failover unlock

[J. Bruce Fields]

On Thu, Feb 14, 2008 at 02:04:28PM -0500, Wendy Cheng wrote:
> Bob Bell wrote:
>> On Mon, Jan 07, 2008 at 12:31:09AM -0500, Wendy Cheng wrote:
>>> 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 ?) ..

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.

Re: [PATCH 0/2] NLM failover unlock

[Chuck Lever]

On Feb 15, 2008, at 11:20 AM, J. Bruce Fields wrote:
> On Thu, Feb 14, 2008 at 02:04:28PM -0500, Wendy Cheng wrote:
>> Bob Bell wrote:
>>> On Mon, Jan 07, 2008 at 12:31:09AM -0500, Wendy Cheng wrote:
>>>> 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 ?) ..
>
> 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?

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

Re: [PATCH 0/2] NLM failover unlock

[J. Bruce Fields]

On Fri, Feb 15, 2008 at 11:30:04AM -0500, Chuck Lever wrote:
> On Feb 15, 2008, at 11:20 AM, J. Bruce Fields wrote:
>> On Thu, Feb 14, 2008 at 02:04:28PM -0500, Wendy Cheng wrote:
>>> Bob Bell wrote:
>>>> On Mon, Jan 07, 2008 at 12:31:09AM -0500, Wendy Cheng wrote:
>>>>> 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 ?) ..
>>
>> 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?
>
> 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.

OK, that'd be fine too.

--b.

Re: [PATCH 0/2] NLM failover unlock

[Wendy Cheng]

J. Bruce Fields wrote:
> 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