a university project! On Sun, Mar 19, 2017 at 11:31 PM, Nithya Balachandran <nbala...@redhat.com> wrote:
> > > On 18 March 2017 at 21:42, Tahereh Fattahi <t28.fatt...@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 <atumb...@redhat.com> >> 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