From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Emelyanov Subject: Re: [PATCH 0/10] fuse: An attempt to implement a write-back cache policy Date: Wed, 04 Jul 2012 11:11:23 +0400 Message-ID: <4FF3EC9B.6030605@parallels.com> References: <4FF3156E.8030109@parallels.com> <87a9zg1b7q.fsf@vostro.rath.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org" , linux-fsdevel To: Nikolaus Rath Return-path: In-Reply-To: <87a9zg1b7q.fsf-sKB8Sp2ER+yL2G7IJ6k9tw@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: fuse-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-fsdevel.vger.kernel.org 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 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 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/