Bug 1643195

(In reply to Prasanna Kumar Kalever from comment #0)
> Description of problem:
> 
> * Right now, we do not have a way to revoke the acquired lock on a file from
> another client.
> * We need a new API something like glfs_lock_revoke() or glfs_lock_break()
> to revoke/break an acquired lock from a different client. 
> 
> 
> See https://github.com/gluster/gluster-block/issues/53 for discussion around
> it.

My two cents -

In general by revocation() word, the assumption is that something which server does (lock/state revocation etc)  when client misbehaves or doesnt respond but not done by another client. 
 WRT the functionality which is being described here as missing, we had had discussions about the same in past for multi-protocol and HA support and we used to refer to it as reclaim_lock(..).

Design discussions can be found below -
https://review.gluster.org/#/c/glusterfs-specs/+/15053/

So what we were trying to achieve is that , when nodeA (gfapi clientA) goes down and fails over to nodeB (gfapi clientB), nodeB sends reclaim_lock request same as original posix/madatory_lock request but with a flag marking it as a reclaim request.

On the server-side, glusterfs lk xlator does conflict checks based on client-id+lk_owner. But on receiving reclaim_lk request, it relaxes that check , which means it checks for only lk-owner and updates the client-id to the nodeB client-id. 

This way, nodeB can reclaim the original lk by a single request and can avoid multiple round-trips (to first revoke, and then re-send lock request). Thoughts?

(In reply to Soumya Koduri from comment #5)
> (In reply to Prasanna Kumar Kalever from comment #0)
> > Description of problem:
> > 
> > * Right now, we do not have a way to revoke the acquired lock on a file from
> > another client.
> > * We need a new API something like glfs_lock_revoke() or glfs_lock_break()
> > to revoke/break an acquired lock from a different client. 
> > 
> > 
> > See https://github.com/gluster/gluster-block/issues/53 for discussion around
> > it.
> 
> My two cents -
> 
> In general by revocation() word, the assumption is that something which
> server does (lock/state revocation etc)  when client misbehaves or doesnt
> respond but not done by another client. 
>  WRT the functionality which is being described here as missing, we had had
> discussions about the same in past for multi-protocol and HA support and we
> used to refer to it as reclaim_lock(..).
> 
> Design discussions can be found below -
> https://review.gluster.org/#/c/glusterfs-specs/+/15053/
> 
> So what we were trying to achieve is that , when nodeA (gfapi clientA) goes
> down and fails over to nodeB (gfapi clientB), nodeB sends reclaim_lock
> request same as original posix/madatory_lock request but with a flag marking
> it as a reclaim request.
> 
> On the server-side, glusterfs lk xlator does conflict checks based on
> client-id+lk_owner. But on receiving reclaim_lk request, it relaxes that
> check , which means it checks for only lk-owner and updates the client-id to
> the nodeB client-id. 
> 
> This way, nodeB can reclaim the original lk by a single request and can
> avoid multiple round-trips (to first revoke, and then re-send lock request).
> Thoughts?

Soumya,
 I have posted a patch here. https://review.gluster.org/#/c/glusterfs/+/21457/

The logic is similar i.e. get the lk-owner,client info and do unlock.

Since this is no longer a priority, closing this