On Wed, Jul 31, 2013 at 6:35 PM, Amar Tumballi <ama...@redhat.com> wrote:
> > Instead, I propose this: >> >> - Revert all of the changes done to fuse-bridge.c, bring it back to the >> state how it was before the patch (carefully considering other changes >> which have happened beyond this patch) >> - Introduce a new translator to overlay a virtual gfid view >> - Normal inodes can continue to return original gfids as-is. >> - Virtual inodes can create a random on-the fly gfid (which need not be >> persisted), and identified by a numerical flag in inode ctx without >> allocating a per-inode object. >> - Upon access of the virtual inodes (which can be identified with an >> integer flag in the inode context without a new structure), redirect the >> operation to the inode which has the gfid whose canonical form is the >> dentry name of the virtual inode. >> >> Let fuse-bridge be a pure fuse <--> xlator converter. Adding a new >> (gfid) view is clearly a separate concern, best implemented as a >> separate translator. >> >> > After looking at 'fuse-resolve.c' changes which would consider gfid mount > options, I myself was thinking about these lines too. Already started with > prototype... should be sending out for review soon (hence lets not > duplicate the effort). > > If anybody else have better suggestion (other than a the 'holy' meta > translator goal itself), do share now, so I can consider it in next > implementation. > > Can I get more review comments on http://review.gluster.org/5497 (and dependent patch?) I see Raghavendra G did some initial reviews, and Avati did few more comments on about approach (as a reply to comment). If the approach taken in patchset is all ok, then I would take it further to handle all fops and take it to completion. One more improvement comment in general. Considering now I got basic implementation of 'discover()' [1], it would be great to take that to completion, and then use that for implementing 'gfid-access' as it makes sense to have 'discover()' in gfid-access, and not lookup(). Regards, Amar [1] - http://review.gluster.org/5545
_______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
