Re: [PATCH 0/10] fuse: An attempt to implement a write-back cache policy

[Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>]

On 07/04/2012 07:01 AM, Nikolaus Rath wrote:
> Hi Pavel,
> 
> I think it's great that you're working on this! I've been waiting for
> FUSE being able to supply write data in bigger chunks for a long time,
> and I'm very excited to see some progress on this. I'm not a kernel
> developer, but I'll be happy to try the patches.

Just to make it clear. I didn't increase the 32 pages per request limit. What
I did is made FUSE submit more than one request at a time while serving massive
writes. So yes, bigger chunks can be now seen by the daemon, but it should read
several requests for that.

> While I try to get this to compile,

That's good news! Thanks a lot!

> a few more questions:

> Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> writes:
>> Hi everyone.
>>
>> 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. E.g. when copying a big file into a FUSE file the cp pushes every
>> 128k to the userspace synchronously. This becomes a problem when the userspace
>> back-end uses networking for storing the data.
>>
>> 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 (depending on the
>> dirty memory limits, but this is much more than 128k) which lets the FUSE daemons
>> handle the size updates in a more efficient manner.
>>
>> The writeback feature is per-connection and is explicitly configurable at the
>> init stage (is it worth making it CAP_SOMETHING protected?)
> 
> From your description it sounds as if the only effect of write-back is
> to increase the chunk size. Why is the a need to require special
> privileges for this?

Provided I understand the code correctly: if FUSE daemon turns writeback on and sets
per-bdi dirty limit too high it can cause a deadlock on the box. Thus then daemon
should be trusted by the kernel, i.e. -- privileged.

>> When the writeback is turned ON:
>>
>> * still copy writeback pages to temporary buffer when sending a writeback request
>>   and finish the page writeback immediately
> 
> Could you elaborate? I don't understand what you're saying here.

This is an implementation detail. To avoid a deadlock in the memory reclaim code
existing FUSE copies a mmapped dirty page contents into a temporary buffer before
sending it to the user space. What I wanted to say here is that I did use the same
trick in the introduced writeback paths. This doesn't affect kernel-to-user API
at all.

> 
> 
> Best,
> 
>    -Nikolaus
> 

Thanks,
Pavel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/