----- Original Message ----- > From: "Raghavendra Bhat" <rabhat@xxxxxxxxxx> > To: "Gluster Devel" <gluster-devel@xxxxxxxxxxx> > Cc: "Anand Avati" <aavati@xxxxxxxxxx> > Sent: Thursday, December 18, 2014 12:31:41 PM > Subject: 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@xxxxxxxxxxx > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
