[Gluster-devel] how does meta xlator work?

[Anand Avati]

On Mon, Aug 11, 2014 at 7:37 PM, Harshavardhana <harsha at harshavardhana.net>
wrote:

> > But there is something I don't get withthe fix:
> > - the code forces direct IO if (state->flags & O_ACCMODE) != O_RDONLY),
> > but here the file is open read/only, hence I would expect fuse xlator to
> > do nothing special
>
> direct_io_mode(xdata) is in-fact gf_true here for 'meta'
>
> > - using direct IO is the kernel's decision, reflecting the flags used by
> > calling process on open(2). How can the fuse xlator convince the kernel
> > to enable it?
> >
>
> fuse is convinced by "FOPEN_DIRECT_IO"  which is pro-actively set when
> 'xdata' is set with
> "direct-io-mode" to "1" by meta module.
>
> From FreeBSD fuse4bsd code
>
> void
> fuse_vnode_open(struct vnode *vp, int32_t fuse_open_flags, struct thread
> *td)
> {
>         /*
>          * Funcation is called for every vnode open.
>          * Merge fuse_open_flags it may be 0
>          *
>          * XXXIP: Handle FOPEN_DIRECT_IO and FOPEN_KEEP_CACHE
>          */
>
>         if (vnode_vtype(vp) == VREG) {
>                 /* XXXIP prevent getattr, by using cached node size */
>                 vnode_create_vobject(vp, 0, td);
>         }
> }
>
>
> FUSE4BSD seems like doesn't even implement this as full functionality.
> Only getpages/putpages API seems to implement "IO_DIRECT" handling.
> Need to see if indeed such is the case.
>
>
I think you found it right. fuse4bsd should start handling FOPEN_DIRECT_IO
in the open handler.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20140811/1574fd72/attachment-0001.html>