[Gluster-devel] Nameless lookup in meta namespace

[Niels de Vos]

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.

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.

Niels
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160812/26e86914/attachment.sig>