<p dir="ltr"></p>
<p dir="ltr">-Atin<br>
Sent from one plus one<br>
On 02-Mar-2016 1:40 pm, "Avra Sengupta" <<a href="mailto:asengupt@redhat.com">asengupt@redhat.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> All fops in NSR, follow a specific workflow as described in this UML(<a href="https://docs.google.com/presentation/d/1lxwox72n6ovfOwzmdlNCZBJ5vQcCaONvZva0aLWKUqk/edit?usp=sharing">https://docs.google.com/presentation/d/1lxwox72n6ovfOwzmdlNCZBJ5vQcCaONvZva0aLWKUqk/edit?usp=sharing</a>). However all locking fops will follow a slightly different workflow as described below. This is a first proposed draft for handling locks, and we would like to hear your concerns and queries regarding the same.<br>
><br>
> 1. On receiving the lock, the leader will Journal the lock himself, and then try to actually acquire the lock. At this point in time, if it fails to acquire the lock, then it will invalidate the journal entry, and return a -ve ack back to the client. However, if it is successful in acquiring the lock, it will mark the journal entry as complete, and forward the fop to the followers.<br>
><br>
> 2. The followers on receiving the fop, will journal it, and then try to actually acquire the lock. If it fails to acquire the lock, then it will invalidate the journal entry, and return a -ve ack back to the leader. If it is successful in acquiring the lock, it will mark the journal entry as complete,and send a +ve ack to the leader.<br>
><br>
> 3. The leader on receiving all acks, will perform a quorum check. If quorum meets, it will send a +ve ack to the client. If the quorum fails, it will send a rollback to the followers.<br>
><br>
> 4. The followers on receiving the rollback, will journal it first, and then release the acquired lock. It will update the rollback entry in the journal as complete and send an ack to the leader.<br>
><br>
> 5. The leader on receiving the rollback acks, will journal it's own rollback, and then release the acquired lock. It will update the rollback entry in the journal, and send a -ve ack to the client.<br>
><br>
> Few things to be noted in the above workflow are:<br>
> 1. It will be a synchronous operation, across the replica volume.<br>
Is this true with existing replication mechanism?<br>
> 2. Reconciliation will take care of nodes who have missed out the locks.<br>
> 3. On a client disconnect, there will be a lock-timeout on whose expiration all locks held by that particular client will be released.<br>
><br>
> Regards,<br>
> Avra<br>
> _______________________________________________<br>
> Gluster-devel mailing list<br>
> <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
> <a href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
</p>