Re: About inode table: client, server and inconsistency

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 






On 22 March 2017 at 12:39, Tahereh Fattahi <t28.fattahi@xxxxxxxxx> wrote:
a university project!

On Sun, Mar 19, 2017 at 11:31 PM, Nithya Balachandran <nbalacha@xxxxxxxxxx> wrote:


On 18 March 2017 at 21:42, Tahereh Fattahi <t28.fattahi@xxxxxxxxx> 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@xxxxxxxxxx> wrote:


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



--
Amar Tumballi (amarts)


_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel



_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux