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? 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? 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... -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- 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
