From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nikolaus Rath Subject: Re: [PATCH 0/10] fuse: An attempt to implement a write-back cache policy Date: Wed, 04 Jul 2012 09:22:19 -0400 Message-ID: <4FF4438B.8050807@rath.org> References: <4FF3156E.8030109@parallels.com> <87a9zg1b7q.fsf@vostro.rath.org> <4FF3EC9B.6030605@parallels.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: "fuse-devel@lists.sourceforge.net" , linux-fsdevel To: Pavel Emelyanov Return-path: Received: from ebox.rath.org ([173.255.235.238]:59597 "EHLO ebox.rath.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750923Ab2GDNW0 (ORCPT ); Wed, 4 Jul 2012 09:22:26 -0400 In-Reply-To: <4FF3EC9B.6030605@parallels.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 07/04/2012 03:11 AM, Pavel Emelyanov wrote: > 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 fo= r >> FUSE being able to supply write data in bigger chunks for a long tim= e, >> 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. >=20 > Just to make it clear. I didn't increase the 32 pages per request lim= it. What > I did is made FUSE submit more than one request at a time while servi= ng massive > writes. So yes, bigger chunks can be now seen by the daemon, but it s= hould read > several requests for that. Ah, I thought that your patch would do both. So with the patch an userspace client can now writes data in say 4 kb chunks, and the FUSE daemon will still receive it from the kernel in 128 kb chunks? But if the client writes a say 1 MB chunk, the FUSE daemon will still see 8 128kb write requests? Would it be very hard to raise the 32 pages per request limit at the same time? >>> A good solution of this is switching the FUSE page cache into a wri= te-back policy. >>> With this file data are pushed to the userspace with big chunks (de= pending on the >>> dirty memory limits, but this is much more than 128k) which lets th= e FUSE daemons >>> handle the size updates in a more efficient manner. >>> >>> The writeback feature is per-connection and is explicitly configura= ble 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? >=20 > Provided I understand the code correctly: if FUSE daemon turns writeb= ack 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? Thanks, -Nikolaus --=20 =C2=BBTime flies like an arrow, fruit flies like a Banana.=C2=AB 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html