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... > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
