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

[Tahereh Fattahi]

Thank you very much.
Is it possible to change something in server inode table during a fop from
client? (I want to change the dht_layout of a directory when create a file
in that directory, but I dont know how send the changed layout to servers)

On Sat, Mar 18, 2017 at 6:36 PM, Amar Tumballi <atumball at redhat.com> wrote:

>
>
> 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/10679e44/attachment-0001.html>