On Thu, May 10, 2012 at 6:58 AM, Jeff Darcy <[email protected]> wrote:
> On Thu, 10 May 2012 15:55:55 +1000 > "Ian Latter" <[email protected]> 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
_______________________________________________ Gluster-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/gluster-devel
