[Gluster-devel] Fuse operations

Anand Avati anand.avati at gmail.com
Thu May 10 19:36:26 UTC 2012

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.

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

More information about the Gluster-devel mailing list