On Thu, Mar 16, 2017 at 10:30 PM, Tahereh Fattahi <t28.fattahi@xxxxxxxxx> wrote:
HiIs 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
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
--
Amar Tumballi (amarts)
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
