Re: explicit lookup of inods linked via readdirp

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

 



On Thursday 18 December 2014 12:58 PM, Raghavendra Gowdappa wrote:

----- 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.

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@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://www.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