<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 29, 2016 at 12:52 PM, Susant Palai <span dir="ltr"><<a href="mailto:spalai@redhat.com" target="_blank">spalai@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Raghavendra,<br>
I have a question on the design.<br>
<br>
Currently in case of a client disconnection, pl_flush cleans up the locks associated with the fd created from that client.<br>
>From the design, rebalance will migrate the locks to the new destination. Now in case client gets disconnected from the<br>
destination brick, how it is supposed to clean up the locks as rebalance/brick have no idea whether the client has opened<br>
an fd on destination and what the fd is.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
So the question is how to associate the client fd with locks on destination.<br></blockquote><div><br></div><div style="">We don't use fds to cleanup the locks during flush. We use lk-owner which doesn't change across migration. Note that lk-owner for posix-locks is filled by the vfs/kernel where we've glusterfs mount.</div><div style=""><br></div><div style=""><pl_flush></div><div style=""> pthread_mutex_lock (&pl_inode->mutex);</div><div> {</div><div> __delete_locks_of_owner (pl_inode, frame->root->client,</div><div> &frame->root->lk_owner);</div><div> }</div><div> pthread_mutex_unlock (&pl_inode->mutex);</div><div style=""></pl_flush></div><div style=""><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Thanks,<br>
Susant<br>
<div class=""><div class="h5"><br>
----- Original Message -----<br>
From: "Susant Palai" <<a href="mailto:spalai@redhat.com">spalai@redhat.com</a>><br>
To: "Gluster Devel" <<a href="mailto:gluster-devel@gluster.org">gluster-devel@gluster.org</a>><br>
Sent: Friday, 29 January, 2016 3:15:14 PM<br>
Subject: [Gluster-devel] Posix lock migration design<br>
<br>
Hi,<br>
Here, [1]<br>
<a href="https://docs.google.com/document/d/17SZAKxx5mhM-cY5hdE4qRq9icmFqy3LBaTdewofOXYc/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/document/d/17SZAKxx5mhM-cY5hdE4qRq9icmFqy3LBaTdewofOXYc/edit?usp=sharing</a><br>
is a google document about proposal for "POSIX_LOCK_MIGRATION". Problem statement and design are explained in the document it self.<br>
<br>
Requesting the devel list to go through the document and comment/analyze/suggest, to take the thoughts forward (either on the<br>
google doc itself or here on the devel list).<br>
<br>
<br>
Thanks,<br>
Susant<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" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><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" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Raghavendra G<br></div>
</div></div>