[Gluster-devel] REVERT: Change in glusterfs[master]: fuse: auxiliary gfid mount support

Amar Tumballi amarts at gmail.com
Fri Aug 9 16:30:37 UTC 2013


On Wed, Jul 31, 2013 at 6:35 PM, Amar Tumballi <amarts at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130809/f04999cd/attachment-0001.html>


More information about the Gluster-devel mailing list