On Wed, Jul 31, 2013 at 6:35 PM, Amar Tumballi <amarts@xxxxxxxxxx> wrote:
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).
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.
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
