----- Original Message ----- > From: "Raghavendra Bhat" <rab...@redhat.com> > To: "Gluster Devel" <gluster-devel@gluster.org> > Cc: "Anand Avati" <aav...@redhat.com> > Sent: Thursday, December 18, 2014 12:31:41 PM > Subject: [Gluster-devel] explicit lookup of inods linked via readdirp > > > Hi, > > In fuse I saw, that as part of resolving a inode, an explicit lookup is > done on it if the inode is found to be linked via readdirp (At the time > of linking in readdirp, fuse sets a flag in the inode context). It is > done because, many xlators such as afr depend upon lookup call for many > things such as healing.
Yes. But the lookup is a nameless lookup and hence is not sufficient enough. Some of the functionalities that get affected AFAIK are: 1. dht cannot create/heal directories and their layouts. 2. afr cannot identify gfid mismatch of a file across its subvolumes, since to identify a gfid mismatch we need a name. >From what I heard, afr relies on crawls done by self-heal daemon for >named-lookups. But dht is worst hit in terms of maintaining directory >structure on newly added bricks (this problem is slightly different, since we >don't hit this because of nameless lookup after readdirp. Instead it is >because of a lack of named-lookup on the file after a graph switch. >Neverthless I am clubbing both because a named lookup would've solved the >issue). I've a feeling that different components have built their own way of >handling what is essentially same issue. Its better we devise a single >comprehensive solution. > > But that logic is not there in gfapi. I am thinking of introducing that > mechanism in gfapi as well, where as part of resolve it checks if the > inode is linked from readdirp. And if so it will do an explicit lookup > on that inode. As you've mentioned a lookup gives a chance to afr to heal the file. So, its needed in gfapi too. However you've to speak to afr folks to discuss whether nameless lookup is sufficient enough. > > NOTE: It can be done in NFS server as well. Dht in NFS setup is also hit because of lack of named-lookups resulting in non-healing of directories on newly added brick. > > Please provide feedback. > > Regards, > Raghavendra Bhat > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > _______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
