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

[Nithya Balachandran]

On 18 March 2017 at 21:42, Tahereh Fattahi <t28.fattahi at gmail.com> wrote:

> 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)
>

Why do you want  to change the layout when files are created?

Regards,
Nithya

>
> 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)
>>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170320/d24df77f/attachment.html>