Re: [Gluster-devel] About inode table: client, server and inconsistency
On 22 March 2017 at 12:39, Tahereh Fattahi wrote: > a university project! > > On Sun, Mar 19, 2017 at 11:31 PM, Nithya Balachandran > wrote: > >> >> >> On 18 March 2017 at 21:42, Tahereh Fattahi 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 >>> wrote: >>> On Thu, Mar 16, 2017 at 10:30 PM, Tahereh Fattahi < t28.fatt...@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@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-devel > -- Amar Tumballi (amarts) >>> >>> >>> ___ >>> Gluster-devel mailing list >>> Gluster-devel@gluster.org >>> http://lists.gluster.org/mailman/listinfo/gluster-devel >>> >> >> > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] About inode table: client, server and inconsistency
a university project! On Sun, Mar 19, 2017 at 11:31 PM, Nithya Balachandran wrote: > > > On 18 March 2017 at 21:42, Tahereh Fattahi 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 >> wrote: >> >>> >>> >>> On Thu, Mar 16, 2017 at 10:30 PM, Tahereh Fattahi >> > 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@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel >>> >>> >>> >>> -- >>> Amar Tumballi (amarts) >>> >> >> >> ___ >> Gluster-devel mailing list >> Gluster-devel@gluster.org >> http://lists.gluster.org/mailman/listinfo/gluster-devel >> > > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] About inode table: client, server and inconsistency
On 18 March 2017 at 21:42, Tahereh Fattahi 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 > wrote: > >> >> >> On Thu, Mar 16, 2017 at 10:30 PM, Tahereh Fattahi >> 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@gluster.org >>> http://lists.gluster.org/mailman/listinfo/gluster-devel >>> >> >> >> >> -- >> Amar Tumballi (amarts) >> > > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] About inode table: client, server and inconsistency
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 wrote: > > > On Thu, Mar 16, 2017 at 10:30 PM, Tahereh Fattahi > 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@gluster.org >> http://lists.gluster.org/mailman/listinfo/gluster-devel >> > > > > -- > Amar Tumballi (amarts) > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] About inode table: client, server and inconsistency
On Thu, Mar 16, 2017 at 10:30 PM, Tahereh Fattahi 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@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-devel > -- Amar Tumballi (amarts) ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] About inode table: client, server and inconsistency
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? Does all inode tables store in RAM all the time? 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) ? ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
