Re: [fuse-devel] Low-level file system and out of order requests handling

[Goswin v. B. <gos...@we...>]

On Fri, Jan 04, 2013 at 05:21:35PM +0100, Tomasz Jankowski wrote:
> Hello,
> 
> I'm implementing low-level file system for network application. After
> mounting file system, I'm obtaining FUSE file descriptor and watch on it
> with epoll. When data arrives I handle it using "fuse_chan_recv()" and
> "fuse_session_process()". I have two questions:
> 
>    1. Can I process requests out of order? In my file system some data
>    (e.g. attributes, directories tree) is stored in RAM, so I can handle some
>    requests (lookup, readdir, getattr etc.) immediately. For other requests I
>    have to transfer data over network. So if I first receive open request and
>    then getattr, can I handle gettattr first and then open?

Short ansere: yes.

Every request has an unique 64bit id in the request structure. All the
reply functions take the request as first argument to get that id.
You can reply to requests in any order you like.

You have two options to handle the requests out of order:

1) Create worker threads and hand of each request to worker. Each worker
   then processes the request with blocking IO and replies when it is done.

2) Use non-blocking IO and keep track of all pending requests within a single
   thread.

You can also combine the two. E.g. have one main thread that handles
the fuse_chan_recv() and fuse_session_process(). Requests that can
work with cached data you can handle directly. Requests that need
networking you hand of to the networking thread(s).

What you do there is mostly a matter of taste.

>    2. Is there any way to check if there are pending requests other then
>    blocking on "fuse_chan_recv()"? I found, that ioctl & FIONREAD and making
>    FUSE file descriptor non-blocking is not recommended.

/**
 * Query the file descriptor of the channel
 *
 * @param ch the channel
 * @return the file descriptor passed to fuse_chan_new()
 */
int fuse_chan_fd(struct fuse_chan *ch);

Add that FD to your epoll. If the FD is ready for read then
fuse_chan_recv() will never block.
 
> Bye!

MfG
	Goswin