gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] REVERT: Change in glusterfs[master]: fuse: auxiliary


From: Amar Tumballi
Subject: Re: [Gluster-devel] REVERT: Change in glusterfs[master]: fuse: auxiliary gfid mount support
Date: Fri, 9 Aug 2013 22:00:37 +0530

On Wed, Jul 31, 2013 at 6:35 PM, Amar Tumballi <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]