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@xxxxxxxxxxxxx> 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 -- 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
