<div dir="ltr">On Wed, Jul 31, 2013 at 6:35 PM, Amar Tumballi <span dir="ltr"><<a href="mailto:amarts@redhat.com" target="_blank">amarts@redhat.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Instead, I propose this:<br>
<br>
- Revert all of the changes done to fuse-bridge.c, bring it back to the<br>
state how it was before the patch (carefully considering other changes<br>
which have happened beyond this patch)<br>
- Introduce a new translator to overlay a virtual gfid view<br>
- Normal inodes can continue to return original gfids as-is.<br>
- Virtual inodes can create a random on-the fly gfid (which need not be<br>
persisted), and identified by a numerical flag in inode ctx without<br>
allocating a per-inode object.<br>
- Upon access of the virtual inodes (which can be identified with an<br>
integer flag in the inode context without a new structure), redirect the<br>
operation to the inode which has the gfid whose canonical form is the<br>
dentry name of the virtual inode.<br>
<br>
Let fuse-bridge be a pure fuse <--> xlator converter. Adding a new<br>
(gfid) view is clearly a separate concern, best implemented as a<br>
separate translator.<br>
<br>
</blockquote>
<br></div>
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).<br>
<br>
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.<br>
<br></blockquote><div><br></div><div>Can I get more review comments on <a href="http://review.gluster.org/5497">http://review.gluster.org/5497</a> (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.<br>
</div><div><br></div><div>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().</div>
<div><br></div><div>Regards,</div><div>Amar</div><div><br></div><div>[1] - <a href="http://review.gluster.org/5545">http://review.gluster.org/5545</a></div></div></div></div>