<div dir="ltr"><div dir="ltr">On Wed, Mar 27, 2019 at 11:54 AM Raghavendra Gowdappa <<a href="mailto:rgowdapp@redhat.com">rgowdapp@redhat.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 27, 2019 at 4:22 PM Raghavendra Gowdappa <<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 27, 2019 at 12:56 PM Xavi Hernandez <<a href="mailto:jahernan@redhat.com" target="_blank">jahernan@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Raghavendra,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 27, 2019 at 2:49 AM Raghavendra Gowdappa <<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>All,<br><br>Glusterfs cleans up POSIX locks held on an fd when the client/mount
through which those locks are held disconnects from bricks/server. This
helps Glusterfs to not run into a stale lock problem later (For eg., if
application unlocks while the connection was still down). However, this
means the lock is no longer exclusive as other applications/clients can
acquire the same lock. To communicate that locks are no longer valid, we
are planning to mark the fd (which has POSIX locks) bad on a disconnect
so that any future operations on that fd will fail, forcing the
application to re-open the fd and re-acquire locks it needs [1].<br></div></div></blockquote><div><br></div><div>Wouldn't it be better to retake the locks when the brick is reconnected if the lock is still in use ?</div></div></div></blockquote><div><br></div><div>There is also a possibility that clients may never reconnect. That's the primary reason why bricks assume the worst (client will not reconnect) and cleanup the locks.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>BTW, the referenced bug is not public. Should we open another bug to track this ?</div></div></div></blockquote><div><br></div><div>I've just opened up the comment to give enough context. I'll open a bug upstream too.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>Note that with AFR/replicate in picture we can prevent errors to application as long as Quorum number of children "never ever" lost connection with bricks after locks have been acquired. I am using the term "never ever" as locks are not healed back after re-connection and hence first disconnect would've marked the fd bad and the fd remains so even after re-connection happens. So, its not just Quorum number of children "currently online", but Quorum number of children "never having disconnected with bricks after locks are acquired".<br></div></div></blockquote><div><br></div><div>I think this requisite is not feasible. In a distributed file system, sooner or later all bricks will be disconnected. It could be because of failures or because an upgrade is done, but it will happen.</div><div><br></div><div>The difference here is how long are fd's kept open. If applications open and close files frequently enough (i.e. the fd is not kept open more time than it takes to have more than Quorum bricks disconnected) then there's no problem. The problem can only appear on applications that open files for a long time and also use posix locks. In this case, the only good solution I see is to retake the locks on brick reconnection.</div></div></div></blockquote><div><br></div><div>Agree. But lock-healing should be done only by HA layers like AFR/EC as only they know whether there are enough online bricks to have prevented any conflicting lock. Protocol/client itself doesn't have enough information to do that. If its a plain distribute, I don't see a way to heal locks without loosing the property of exclusivity of locks.<br><br></div><div>What I proposed is a short term solution. mid to long term solution should be lock healing feature implemented in AFR/EC. In fact I had this conversation with <a class="gmail_plusreply" id="gmail-m_-2147697475493656246gmail-m_-7682098365631184519plusReplyChip-0" href="mailto:pkarampu@redhat.com" target="_blank">+Karampuri, Pranith</a> before posting this msg to ML.<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>However, this use case is not affected if the application don't
acquire any POSIX locks. So, I am interested in knowing <br>* whether your use cases use POSIX locks?<br></div>* Is it feasible for your application to re-open fds and re-acquire locks on seeing EBADFD errors?<br></div></blockquote><div><br></div><div>I think that many applications are not prepared to handle that.</div></div></div></blockquote><div><br></div><div>I too suspected that and in fact not too happy with the solution. But went ahead with this mail as I heard implementing lock-heal in AFR will take time and hence there are no alternative short term solutions.<br></div></div></div></blockquote><div><br></div><div>Also failing loudly is preferred to silently dropping locks.<br></div></div></div></blockquote><div><br></div><div>Yes. Silently dropping locks can cause corruption, which is worse. However causing application failures doesn't improve user experience either.</div><div><br></div><div>Unfortunately I'm not aware of any other short term solution right now.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Xavi</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>[1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1689375#c7" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1689375#c7</a><br><div><br></div><div>regards,<br></div><div>Raghavendra<div class="gmail-m_-2147697475493656246gmail-m_-7682098365631184519gmail-m_2829317191536857760gmail-m_-100542626364393863gmail-adL"><br></div></div></div></div>
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-users</a></blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>
</blockquote></div></div>