<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 16, 2017 at 10:30 PM, Tahereh Fattahi <span dir="ltr">&lt;<a href="mailto:t28.fattahi@gmail.com" target="_blank">t28.fattahi@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span style="font-size:12.8px">Hi</span><div style="font-size:12.8px">Is it correct that each brick has one inode table for itself and each client has one inode table that stores anything that is stored in bricks inode table?</div><div style="font-size:12.8px"><br></div></div></blockquote><div>For a given inode, the contents on client side and server side would be very much different between how the volume graph is.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:12.8px"></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Does all inode tables store in RAM all the time?</div></div></blockquote><div><br></div><div>Client (mainly fuse) inode table will be in memory all the time, until kernel sends a FORGET. Brick side we have limited number of inodes in memory. (There is an option called &#39;lru-limit&#39;).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div style="font-size:12.8px"><br></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">When and how client&#39;s inode table update (how solve the inconsistency problem between clinet and brick inode table that is because of rebalance or other client fops) ?</div></div>
<br></blockquote><div><br></div><div>All the translators are designed to handle the consistency check in their &#39;lookup()&#39; code, and they should send a response up with error saying its a stale inode (ESTALE), upon receiving which, the client inode table refreshes its inode, and does a fresh lookup again. This allows us to keep the inode table in consistency.<br><br></div><div>Hope that answers the question.<br><br></div><div>-Amar<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">______________________________<wbr>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://lists.gluster.org/<wbr>mailman/listinfo/gluster-devel</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Amar Tumballi (amarts)<br></div></div></div></div></div>
</div></div>