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

[Nithya Balachandran]

On 22 March 2017 at 12:39, Tahereh Fattahi <t28.fattahi at gmail.com> wrote:

> a university project!
>
> On Sun, Mar 19, 2017 at 11:31 PM, Nithya Balachandran <nbalacha at redhat.com
> > wrote:
>
>>
>>
>> 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)
>>>
>>
The changed layout is not stored in the inode table of the servers. Take a
look at dht_fix_layout_of_directory to see what happens to update the
layout.

I have opened an issue to track additional developer specific info in the
glusterdocs. Please feel free to update this with your questions and we
will see that the documentation is updated.

https://github.com/gluster/glusterdocs/issues/225

>
>> 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/20170325/529b7b2a/attachment.html>