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

[Wendy Cheng <wcheng@redhat.com>]

Neil Brown wrote:

>On Thursday April 26, wcheng@redhat.com wrote:
>  
>
>>A convincing argument... unfortunately, this happens to be a case where 
>>we need to protect server from client's misbehaviors. For a local 
>>filesystem (ext3), if any file reference count is not zero (i.e. some 
>>clients are still holding the locks), the filesystem can't be 
>>un-mounted. We would have to fail the failover to avoid data corruption.
>>    
>>
>
>I think this is a tangential problem.
>"removing locks held by troublesome clients so that I can unmount my
>filesystem" is quite different from "remove locks held by client
>clients using virtual-NAS-foo so they can be migrated".
>  
>
The reason to unmount is because we want to migrate the virtual IP. IMO 
they are the same issue but it is silly to keep fighting about this. In 
any case, one interface is better than two, if you allow me to insist on 
this.

So how about we do RPC call to lockd to tell it to drop the locks owned 
by the client/local-IP pair as you proposed, *but* add an "OR" with fsid 
to fool proof the process ? Say something like this:

RPC_to_lockd_with (client_host, client_ip, fsid);
if ((host == client_host && vip == client_ip) ||
(get_fsid(file) == client_fsid))
drop_the_locks();

This logic (RPC to lockd) will be triggered by a new command added to 
nfs-util package.

If we can agree on this, the rest would be easy. Done ?

-- Wendy

-------------------------------------------------------------------------
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs