On Thu, Mar 16, 2017 at 10:30 PM, Tahereh Fattahi <[email protected]> wrote:
> Hi > 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? > > For a given inode, the contents on client side and server side would be very much different between how the volume graph is. > > Does all inode tables store in RAM all the time? > 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 'lru-limit'). > > > When and how client's inode table update (how solve the inconsistency > problem between clinet and brick inode table that is because of rebalance > or other client fops) ? > > All the translators are designed to handle the consistency check in their 'lookup()' 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. Hope that answers the question. -Amar > _______________________________________________ > Gluster-devel mailing list > [email protected] > http://lists.gluster.org/mailman/listinfo/gluster-devel > -- Amar Tumballi (amarts)
_______________________________________________ Gluster-devel mailing list [email protected] http://lists.gluster.org/mailman/listinfo/gluster-devel
