<html><head></head><body><div>On Tue, 2016-03-01 at 11:40 +0530, Raghavendra G wrote:</div><blockquote type="cite"><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 type="cite">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 type="cite"><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></div></div></blockquote><div><br></div><div>A small note:</div><div>Since we don't set lk_owner for gfapi-based glusterfs clients, in those scenarios frame->root->lk_owner is being calculated out of bit-wise shift operations done on pid of the client.</div><div><br></div><div><rpc_clnt_record></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>. . .</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>if (call_frame->root->lk_owner.len)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>au.lk_owner.lk_owner_val = call_frame->root->lk_owner.data;</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>else {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>owner[0] = (char)(au.pid & 0xff);</div><div> owner[1] = (char)((au.pid >> 8) & 0xff);</div><div> owner[2] = (char)((au.pid >> 16) & 0xff);</div><div> owner[3] = (char)((au.pid >> 24) & 0xff);</div><div> au.lk_owner.lk_owner_val = owner;</div><div> au.lk_owner.lk_owner_len = 4;</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>. . .</div><div></rpc_clnt_record></div><div><br></div><div>To address this issue, we have <a href="http://review.gluster.org/#/c/12876/">http://review.gluster.org/#/c/12876/</a> which will expose a public api to set lk_owner for gfapi_based clients.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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 type="cite">
<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><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Raghavendra G<br></div>
</div></div>
<pre>_______________________________________________
Gluster-devel mailing list
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a></pre></blockquote></body></html>