tech-kern archive

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

let FS force FDIRECT



Hi

I have hit a FUSE feature that seems to require a bit of kernel hacking to 
be supported on NetBSD: At open() time, a FUSE filesystem returns a set
of flags to the kernel, one of them being FOPEN_DIRECT_IO. It tells the 
kernel that access to this file must bypass the page cache. 

It is used for /proc-like features. For instance, glusterFS has a /.meta 
directory with dynamically filled files that tell things about the FS
itself. Since it is dynamically generated, LOOKUP on the file get metadata
with size sets as 0. When we need to read the file, PUFFS does not send
a requesto to the FS since page cache is enabled for the whole filesystem, 
and in that case, a READ request beyond end of file is handled within the 
kernel. 

Supporting direct I/O at PUFFS level is easy: for a file_t, when f_flags
has FDIRECT, vn_read() calls VOP_READ with IO_DIRECT in ioflags. 
puffs_vnop_read() can just look at (ioflags & IO_DIRECT) and decide to 
bypass the page cache for this given operation.

But the tricky  part is that puffs_vnop_open() should be able to set FDIRECT
in file_t's f_flags when the usrland FS replies with the FOPEN_DIRECT_IO.
puffs_vnop_open() does not see the file_t, it sees the struct vnode, hence
it cannot set FDIRECT right now.

A possible solution would be to turn into an (int *) the a_mode in VOP_OPEN(),
and fmode invn_open(), so that ths method implementing OPEN in FS 
(here puffs_vnop_open) can change the flags and have the new value 
propagated to file_t's f_flags. But that is a heavy change and it modify
the VFS interface.

A less intrusive way is to cheat and just add a VV_IO_DIRECT flag for struct
vnode's v_vflag. puffs_vnoop_open() could set it without any VFS interface
modification, and VOP_READ() could use it to force IO_DIRECT. 

The later is cheating because we cannot support the situation where the
filesystem tells us to use direct IO on a file descriptor and not on another
one. But I am not sure it could make sense from a FS point of view.

Any opinion on this?

-- 
Emmanuel Dreyfus
manu%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index