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. While I try to get this to compile, 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? > 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. Best, -Nikolaus -- »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
