Re: [Gluster-devel] explicit lookup of inods linked via readdirp
On Thursday 18 December 2014 12:58 PM, Raghavendra Gowdappa wrote: - 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. As per my understanding, this change in gfapi creates same chances as that of fuse. When I tried with fuse, where I had a file that need to be healed, doing ls, and cat file actually triggered a selfheal on it. So even with gfapi, the change creates same chances of healing as that of fuse. Regards, Raghavendra Bhat 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 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[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. 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. NOTE: It can be done in NFS server as well. Please provide feedback. Regards, Raghavendra Bhat ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] explicit lookup of inods linked via readdirp
- 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
Re: [Gluster-devel] explicit lookup of inods linked via readdirp
+Pranith - Original Message - From: Raghavendra Gowdappa rgowd...@redhat.com To: Raghavendra Bhat rab...@redhat.com Cc: Anand Avati aav...@redhat.com, Gluster Devel gluster-devel@gluster.org Sent: Thursday, December 18, 2014 12:58:27 PM Subject: Re: [Gluster-devel] explicit lookup of inods linked via readdirp - 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 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
