[Gluster-devel] About inode table: client, server and inconsistency

[Amar Tumballi]

On Thu, Mar 16, 2017 at 10:30 PM, Tahereh Fattahi <t28.fattahi at gmail.com>
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
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170318/9d0613f2/attachment.html>