Re: how does meta xlator work?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux