<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><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">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>After giving this some more thought, I feel the cleanest way is to make inode_t and inode table graph aware. This way for a given GFID there will be one and only one inode_t at a given time no matter how many graphs are switched. It is also worth noting that relationship between two GFIDs does not change with a graph switch, so having a separate inode table with duplicate inodes and dentries has always been redundant in a way. The initial decision to have separate inode table per graph was done because inode table was bound to an xlator_t (which in turn was bound to a graph).</div>
<div><br></div></div></div></div></blockquote><div><br></div><div>Initial design / implementation of this is @ <a href="http://review.gluster.org/6046">http://review.gluster.org/6046</a> Please review the way its handled...</div>
<div> </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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div></div><div>If we make inode_t and inode table multi-graph aware, the same inode_t would be valid on a new graph. We would need new code to keep track of the latest graph on which a given inode has been "initialized / discovered" in order to force a discover() on new graph if necessary (dentry relations would just continue to be valid), and after a new graph switch, to force cleanup of xlators from old graph.</div>
<div><br></div></div></div></div></blockquote><div><br></div><div>This is not yet addressed with the above patch, and I would need some help there..</div><div> </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">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Another reason why I prefer this new approach is, making inode_t graph independent makes old graph destruction completely "in our control", without having to depend on /force fuse to issue FORGET on inode_ts from the old graph. That entire problem gets eliminated as inode_ts would now be graph independent.</div>
<div><br></div><div>(copying Raghavendra Bhat who is performing graph destruction work and Amar)</div><div><br></div><div>Thoughts?</div><div><div class="h5"><div><br></div></div></div></div></div></div></blockquote><div>
Now after implementing the suggested method, I feel its much better for overall dynamic graph/volume management. makes the code simple.</div><div><br></div><div>Regards,</div><div>Amar</div></div></div></div>