[ATTEND][LSF/MM TOPIC] FUSE: write-back cache policy and other improvements

["Maxim V. Patlasov" <mpatlasov@parallels.com>]

Hi,

I'm interested in attending to discuss the latest advances in 
accelerating FUSE and making it more friendly to distributed 
file-systems. I'd like to propose and participate in the following 
discussions in the upcoming LSF/MM:

* write-back cache policy: one of the problems with the existing FUSE 
implementation is that it uses the write-through cache policy which 
results in performance problems on certain workloads. A good solution of 
this is switching the FUSE page cache into a write-back policy. With 
this file data are pushed to the userspace with big chunks which lets 
the FUSE daemons handle requests in a more efficient manner.

* optimize scatter-gather direct IO: dio performance can be improved 
significantly by stuffing many io-vectors  into a single fuse request. 
This is especially the case for device virtualization thread performing 
i/o on behalf of virtual-machine it serves.

* process direct IO asynchronously: both AIO and ordinary synchronous 
direct IO can be boosted by submitting fuse requests in non-blocking way 
(where it's possible) and either returning -EIOCBQUEUED or waiting for 
their completions synchronously.

* synchronous close(2): currently, in-kernel fuse sends release request 
to userspace and returns without waiting for ACK from userspace. 
Consequently, there is a gap when user regards the file released while 
userspace fuse is still working on it. This leads to unnecessary 
synchronization complications for file-systems with shared access. That 
behaviour can be fixed by making close(2) synchronous.

* throttle request allocations: currently, in-kernel fuse throttles 
allocations of all fuse requests. Switching to the policy where only 
background requests are throttled would improve the latency of 
synchronous requests and resolve thundering herd problem of waking up 
all threads blocked on fuse request allocations.

Thanks,
Maxim