On 08/12/2016 11:48 AM, Ravishankar N wrote: > On 08/12/2016 11:29 AM, 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. > Can we create a .glusterfs/.meta on the bricks with a fixed gfid (like > .trashcan does)? > We shouldn't allow any operations on it though. meta ops won't reach to server side. meta sits just below to master xlator in client side, and all the fop will served from meta xlators, meaning the ops for meta will only pass through master xlators and meta. eg: fuse->meta meta_cbk->fuse_cbk Rafi KC > > -Ravi >> >> 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? >> >> >> Regards! >> >> Rafi KC >> >> _______________________________________________ >> Gluster-devel mailing list >> Gluster-devel@xxxxxxxxxxx >> http://www.gluster.org/mailman/listinfo/gluster-devel > > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel