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 09:07:00 -0400 Message-ID: <4FF59174.1070102@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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org" , linux-fsdevel To: xemul@parallels.com Return-path: Received: from plane.gmane.org ([80.91.229.3]:50480 "EHLO plane.gmane.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932579Ab2GENHV (ORCPT ); Thu, 5 Jul 2012 09:07:21 -0400 Received: from public by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Smlm6-0000NH-Ra for linux-fsdevel@vger.kernel.org; Thu, 05 Jul 2012 15:07:14 +0200 In-Reply-To: <4FF3EC9B.6030605@parallels.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Pavel Emelyanov writes: >> While I try to get this to compile, > > That's good news! Thanks a lot! Ok, I got it to compile and tested it by copying a large file into an S3QL FUSE file system using different block sizes. At first glance, things look fantastic. With kernel 3.2: Blocksize: 4k 131072000 bytes (131 MB) copied, 7.76037 s, 16.9 MB/s Blocksize: 8k 131072000 bytes (131 MB) copied, 2.48469 s, 52.8 MB/s Blocksize: 16k 131072000 bytes (131 MB) copied, 2.21868 s, 59.1 MB/s Blocksize: 32k 131072000 bytes (131 MB) copied, 2.0455 s, 64.1 MB/s Blocksize: 64k 131072000 bytes (131 MB) copied, 1.83897 s, 71.3 MB/s Blocksize: 96k 131072000 bytes (131 MB) copied, 1.72298 s, 76.1 MB/s Blocksize: 128k 131072000 bytes (131 MB) copied, 2.10194 s, 62.4 MB/s Blocksize: 256k 131072000 bytes (131 MB) copied, 1.96788 s, 66.6 MB/s Blocksize: 512k 131072000 bytes (131 MB) copied, 2.42342 s, 54.1 MB/s Blocksize: 1024k 131072000 bytes (131 MB) copied, 1.6651 s, 78.7 MB/s With 3.5-pre and write-back patches: Blocksize: 4k 131072000 bytes (131 MB) copied, 5.50489 s, 23.8 MB/s Blocksize: 8k 131072000 bytes (131 MB) copied, 1.43694 s, 91.2 MB/s Blocksize: 16k 131072000 bytes (131 MB) copied, 0.967118 s, 136 MB/s Blocksize: 32k 131072000 bytes (131 MB) copied, 0.707767 s, 185 MB/s Blocksize: 64k 131072000 bytes (131 MB) copied, 0.605011 s, 217 MB/s Blocksize: 96k 131072000 bytes (131 MB) copied, 0.573445 s, 229 MB/s Blocksize: 128k 131072000 bytes (131 MB) copied, 0.51943 s, 252 MB/s Blocksize: 256k 131072000 bytes (131 MB) copied, 0.458335 s, 286 MB/s Blocksize: 512k 131072000 bytes (131 MB) copied, 0.452351 s, 290 MB/s Blocksize: 1024k 131072000 bytes (131 MB) copied, 0.446027 s, 294 MB/s 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 an= d 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? 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