[Gluster-devel] Nameless lookup in meta namespace

[Mohammed Rafi K C]

On 08/12/2016 01:31 PM, Niels de Vos wrote:
> On Fri, Aug 12, 2016 at 09:54:30AM +0200, Niels de Vos wrote:
>> On Fri, Aug 12, 2016 at 11:29:34AM +0530, Mohammed Rafi K C wrote:
>>> Hi,
>>>
>>> As you may probably know meta xlators provide a /proc kind of virtual
>>> name space that can be used to get meta data information for mount
>>> process. We are trying to enhance the meta xlator to support more
>>> features and to support other protocols.
>>>
>>> Currently meta generate gfid by its own and store it to the inode. But
>>> when a graph switch happens fuse send a nameless lookup with a fresh
>>> inode from the new graph to resolve the gfid. But meta doesn't know
>>> about the gfid even though it generated it, because all the information
>>> are stored in inode_ctx of previous inode. So the nameless lookup will fail.
>>>
>>> Basically we need a way to resolve gfid from meta xlators. Or otherwise
>>> as meta xlators provide meta data of process, we can restrict the access
>>> to per graph basis. If a graph change happens , we can treat it as the
>>> directory as deleted and recreated with different gfid. We have to
>>> access it again to get information from new graph.
>>>
>>> Thoughts?
>> How about taking the path+filename in the meta-xlator and generate the
>> GFID based on that? meta should not need to manage hardlinks, so there
>> wont be multuple filenames for the same GFID.
> Well, of course this is not complete... (/me blames the lack of coffee)
>
> There need to be a way to go from GFID to inode, even if the inode was
> never looked-up in the meta xlator. The filehandle that an NFS-client
> receives from an NFS-server should stay valid on server reboot, or
> fail-over to an other NFS-server.
I haven't thought about server reboot and fail-over, it is a good catch.


>
> Without pushing the gfid to the bricks, I'm not sure how else it is
> possible. Maybe meta should create the files on the bricks, but only as
> empty files, and handle the read/write by itself without winding along.
We can think about the solution, I will brainstorm it .

Again many thanks for the suggestion.


Rafi KC
>
> Niels