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).
Initial design / implementation of this is @ http://review.gluster.org/6046 Please review the way its handled...
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.
This is not yet addressed with the above patch, and I would need some help there..
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.(copying Raghavendra Bhat who is performing graph destruction work and Amar)Thoughts?
Now after implementing the suggested method, I feel its much better for overall dynamic graph/volume management. makes the code simple.
Regards,
Amar
