> 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
