Re: [fuse-devel] Where is the opcode?

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

Stef Bon <st...@gm...> writes:

> 2011/2/3 Goswin von Brederlow <gos...@we...>:
>> Stef Bon <st...@gm...> writes:
>>
>
>>> I will call it fuse_loop_epoll_mt.c. If anyone interested, let me know.
>>>
>>> Stef
>>
>> Still, why not have all the worker threads just epoll?
>>
>> MfG
>>        Goswin
>>
>>
>
> Well It's possible, of course, but then wont't the different epoll
> listning to the same set of fd's not conflict?. There is at least on
> fd for fuse, and maybe more for other services, and if every thread is
> watching these fd's at the same time.. I do not know this will work
> out good.
>
> The thread "taking" action has to announce that he is taking action,
> and the others do not have to do anything. Some sort of messaging
> between the threads is required I think. So this will make it
> unnecessary difficult.
>
> Stef

I strongly believe that for every event only one thread will return from
epoll_wait. And that thread then takes action on the event(s) it got.

It might be a good idea to set maxevents=1 so when 2 events come in
simultaneous 2 threads will be woken up. This doesn't scale well though
if you have verry many events due to the overhead of system call. But a
fuse filesystem shouldn't have that many events in parallel. The number
of parallel filesystem operations is limited and quite low (compared to
where event storms would become an issue).

So you do not need any thread communication to coordinate which thread
handles which event. But the filesystem might have to use some for
consitency of its datastructures. But that depends on what kind of
filesystem you write.



>From my side I only see one design making sense with epoll and kaio. You
write your filesystem completly single threaded but able to handle
multiple requests in parallel. Extra worker threads for cpu intensive
things like calculating a sha sum for a block might make sense to
utilize multiple cores. But only to utilize multiple cores. Not to
handle requests in parallel.

If you are going to use threads to simulate asynchronous readdir(),
readlink(), ... calls while using true asynchronous IO for read/write
then my opinion remains that then you should just use the multithreaded
fuse loop and do synchronous IO. That will give you a much simpler and
uniform design and you don't have to care about wether the host has kaio
or posix aio (which is just therads anyway). But that might just be me.


Back to the original question of where the opcode is:

You can recieve the fuse request from the fuse channel and pass that off
to a worker thread and have it call the fuse process function. That then
decodes the requests and calls the callback. Or you can have the epoll
thread call the process function and then have each callback just send a
message to a worker thread. I would do the former.

So instead of sending a char over the pipe you would send the pointer to
the buffer containing the raw requests.

MfG
        Goswin