[Gluster-devel] Fuse operations

[Anand Avati]

On Thu, May 10, 2012 at 6:58 AM, Jeff Darcy <jdarcy at redhat.com> wrote:

> On Thu, 10 May 2012 15:55:55 +1000
> "Ian Latter" <ian.latter at midnightcode.org> wrote:
>
> >   So, I guess;
> >     1) Are all Fuse/FS ops handled by Gluster?
> >     2) Where can I find a complete list of the
> >          Gluster fops, and not just those that have
> >          been used in existing modules?
>
> GlusterFS operations for a translator are all defined in an xlator_fops
> structure.  When building translators, it can also be convenient to
> look at the default_xxx and default_xxx_cbk functions for each fop you
> implement.  Also, I forgot to mention in my comments on your "hide"
> translator that you can often use the default_xxx_cbk callback when you
> call STACK_WIND, instead of having to define your own trivial one.
>
> FUSE operations are listed by the fuse_opcode enum.  You can check for
> yourself how closely this matches our list.  They do have a few ops of
> their own, we have a few of their own, and a few of theirs actually map
> to our xlator_cbks instead of xlator_fops.  The points of
> non-correspondence seem to be interrupt, bmap, poll and ioctl.  Maybe
> Csaba can elaborate on what we do (or plan to do) about these.
>
>
We might support interrupt sometime. Bmap - probably never. Poll, maybe.
Ioctl - depeneds on what type of ioctl and requirement.


> >     3) Is it safe to path match on loc_t? (i.e. is
> >          it fully resolved such that I won't find
> >          /etc/././././passwd)?  This I could test ..
>
> Name/path resolution is an area that has changed pretty recently, so
> I'll let Avati or Amar field that one.
>

The ".." interpretation is done by the client side VFS. Internal path
construction does not use ".." and are always normalized. There are new
situations where we now support non-absolute paths, but those are for GFID
based addressing and ".." does not come into picture there.

Avati
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20120510/ee3eed7c/attachment-0003.html>