On Mon, Aug 11, 2014 at 7:37 PM, Harshavardhana <harsha@xxxxxxxxxxxxxxxxxx> wrote:
> But there is something I don't get withthe fix:direct_io_mode(xdata) is in-fact gf_true here for 'meta'
> - 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
fuse is convinced by "FOPEN_DIRECT_IO" which is pro-actively set when
> - 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?
>
'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.
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
