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

[Tahereh Fattahi]

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)
>>
>
> 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/20170322/14565247/attachment-0001.html>