[Gluster-devel] how does meta xlator work?

Harshavardhana harsha at harshavardhana.net
Tue Aug 12 02:37:17 UTC 2014


> 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.

-- 
Religious confuse piety with mere ritual, the virtuous confuse
regulation with outcomes


More information about the Gluster-devel mailing list