Re: explicit lookup of inods linked via readdirp

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



+Pranith

----- Original Message -----
> From: "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx>
> To: "Raghavendra Bhat" <rabhat@xxxxxxxxxx>
> Cc: "Anand Avati" <aavati@xxxxxxxxxx>, "Gluster Devel" <gluster-devel@xxxxxxxxxxx>
> Sent: Thursday, December 18, 2014 12:58:27 PM
> Subject: Re:  explicit lookup of inods linked via readdirp
> 
> 
> 
> ----- 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
> 
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux