<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 30, 2019 at 4:32 PM Xavi Hernandez <<a href="mailto:jahernan@redhat.com">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 dir="ltr">Hi Changwei,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 29, 2019 at 7:56 AM Changwei Ge <<a href="mailto:chge@linux.alibaba.com" target="_blank">chge@linux.alibaba.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">Hi,<br>
<br>
I am recently working on reducing inode_[un]ref() locking contention by <br>
getting rid of inode table lock. Just use inode lock to protect inode <br>
REF. I have already discussed a couple rounds with several Glusterfs <br>
developers via emails and Gerrit and basically get understood on major <br>
logic around.<br>
<br>
Currently, inode REF can be ZERO and be reused by increasing it to ONE.<br>
This is IMO why we have to burden so much work for inode table when <br>
REF/UNREF. It makes inode [un]ref() and inode table and dentries(alias) <br>
searching hard to run concurrently.<br>
<br>
So my question is in what cases, how can we find a inode whose REF is ZERO?<br>
<br>
As Glusterfs store its inode memory address into kernel/fuse, can we <br>
conclude that only fuse_ino_to_inode() can bring back a REF=0 inode?<br></blockquote></div></div></blockquote><div><br></div><div>Xavi's answer below provides some insights. and same time, assuming that only fuse_ino_to_inode() can bring back inode from ref=0 state (for now), is a good start.</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 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"></blockquote><div><br></div><div>Yes, when an inode gets refs = 0, it means that gluster code is not using it anywhere, so it cannot be referenced again unless kernel sends new requests on the same inode. Once refs=0 and nlookup=0, the inode can be destroyed.</div><div><br></div><div>Inode code is quite complex right now and I haven't had time to investigate this further, but I think we could simplify inode management significantly (specially unref) if we add a reference when nlookup becomes > 0, and remove a reference when nlookup becomes 0 again. Maybe with this approach we could avoid inode table lock in many cases. However we need to make sure we correctly handle invalidation logic to keep inode table size under control.</div><div><br></div></div></div></blockquote><div><br></div><div>My suggestion is, don't wait for a complete solution for posting the patch. Let us get a chance to have a look at WorkInProgress patches, so we can have discussions on code itself. It would help to reach better solutions sooner. </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></div><div>Regards,</div><div><br></div><div>Xavi</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">
<br>
<br>
Thanks,<br>
Changwei<br>
_______________________________________________<br>
<br>
Community Meeting Calendar:<br>
<br>
APAC Schedule -<br>
Every 2nd and 4th Tuesday at 11:30 AM IST<br>
Bridge: <a href="https://bluejeans.com/118564314" rel="noreferrer" target="_blank">https://bluejeans.com/118564314</a><br>
<br>
NA/EMEA Schedule -<br>
Every 1st and 3rd Tuesday at 01:00 PM EDT<br>
Bridge: <a href="https://bluejeans.com/118564314" rel="noreferrer" target="_blank">https://bluejeans.com/118564314</a><br>
<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-devel</a><br>
<br>
</blockquote></div></div>
</blockquote></div></div>