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: Thu, 05 Jul 2012 10:29:11 -0400 Message-ID: <4FF5A4B7.4010705@rath.org> References: <4FF3156E.8030109@parallels.com> <87a9zg1b7q.fsf@vostro.rath.org> <4FF3EC9B.6030605@parallels.com> <4FF59174.1070102@rath.org> <4FF59FF5.4030601@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]:37823 "EHLO ebox.rath.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932423Ab2GEO3M (ORCPT ); Thu, 5 Jul 2012 10:29:12 -0400 In-Reply-To: <4FF59FF5.4030601@parallels.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 07/05/2012 10:08 AM, Pavel Emelyanov wrote: > On 07/05/2012 05:07 PM, Nikolaus Rath wrote: >> Pavel Emelyanov writ= es: >>>> While I try to get this to compile, >>> >>> That's good news! Thanks a lot! >=20 > The fuse and fsdevel mainling lists were corrupted in you original me= ssage, > so looping the lists back in. >=20 >> Ok, I got it to compile and tested it by copying a large file into a= n >> S3QL FUSE file system using different block sizes. At first glance, >> things look fantastic. >=20 > That's good news actually! :) >=20 >> With kernel 3.2: >> >> Blocksize: 4k >> 131072000 bytes (131 MB) copied, 7.76037 s, 16.9 MB/s >> >=20 > [snip] >=20 >> >> However, I suspect that most of the gain is really because with the >> patch most of the data is still in the kernel cache when dd finishes= and >> hasn't yet been received by the FUSE client. >> >> >> Is there a way to force flushing of the fuse cache, so that I can >> measure the time for dd + final flush? >=20 > Actually when dd closes an output file the whole page cache which rel= ates to > it gets flushed to the userspace! This is due to how FUSE write reque= sts are > served. >=20 > That said -- you've already measured writeback with flush :) But then how is it possible that there is such a big difference even when using 128kb blocks? Kernel 3.2: 131072000 bytes (131 MB) copied, 2.10194 s, 62.4 MB/s Kernel 3.5-pre: Blocksize: 128k 131072000 bytes (131 MB) copied, 0.51943 s, 252 MB/s I would think that it both cases the FUSE daemon gets the data in 128 k= b packets, so why the difference? Or is this due to some other change between 3.2 and 3.5 that significantly increased FUSE performance? I can try the same test with the unpatched 3.5 tonight if that would be of interest. Best, -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