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

[Pavel Emelyanov <xemul@parallels.com>]

On 07/04/2012 09:08 PM, Nikolaus Rath wrote:
> On 07/04/2012 10:33 AM, Pavel Emelyanov wrote:
>>>>>> 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 the 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.
>>>>
>>>> Wouldn't it be more reasonable to enforce that the bdi dirty limit is
>>>> not set too high then?
>>
>> Hardly, since if you have several mounts with small bdi limit each the sum of them
>> can be still high.
> 
> Yeah, so isn't it possible to put a limit on the sum of them?

Only on FUSE mounts? Currently no, only on the overall dirty set. Which, in turn,
will affect disk filesystems behavior.

> I think it would be much better if this could be made safe to use
> instead of requiring special privileges. If that isn't possible,
> wouldn't it be better to enable/disable the feature in /etc/fuse.conf,
> similar to the user_allow_* options?

I'll look at it.

> Having to explain how to assign capabilities in the documentation of a
> fuse filesystem sounds quite dreadful to me...
> 
> 
> Best,
> 
>    -Nikolaus
> 
> 
> PS: My naive attempt to apply your patches to my Debian 3.2 kernel
> failed. I'm compiling 3.5rc5 at the moment - will see if I can get it to
> boot afterwards...
> 
>