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: Thu, 05 Jul 2012 18:34:27 +0400 Message-ID: <4FF5A5F3.3030707@parallels.com> References: <4FF3156E.8030109@parallels.com> <87a9zg1b7q.fsf@vostro.rath.org> <4FF3EC9B.6030605@parallels.com> <4FF59174.1070102@rath.org> <4FF59FF5.4030601@parallels.com> <4FF5A4B7.4010705@rath.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "fuse-devel@lists.sourceforge.net" , linux-fsdevel To: Nikolaus Rath Return-path: Received: from mailhub.sw.ru ([195.214.232.25]:32701 "EHLO relay.sw.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752133Ab2GEOe7 (ORCPT ); Thu, 5 Jul 2012 10:34:59 -0400 In-Reply-To: <4FF5A4B7.4010705@rath.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 07/05/2012 06:29 PM, Nikolaus Rath wrote: > On 07/05/2012 10:08 AM, Pavel Emelyanov wrote: >> On 07/05/2012 05:07 PM, Nikolaus Rath wrote: >>> Pavel Emelyanov writes: >>>>> While I try to get this to compile, >>>> >>>> That's good news! Thanks a lot! >> >> The fuse and fsdevel mainling lists were corrupted in you original message, >> so looping the lists back in. >> >>> 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. >> >> That's good news actually! :) >> >>> With kernel 3.2: >>> >>> Blocksize: 4k >>> 131072000 bytes (131 MB) copied, 7.76037 s, 16.9 MB/s >>> >> >> [snip] >> >>> >>> 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? >> >> Actually when dd closes an output file the whole page cache which relates to >> it gets flushed to the userspace! This is due to how FUSE write requests are >> served. >> >> 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 kb > 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 don't know for sure. Need to read an analyze the FUSE userspace side logs (if any). > I can try the same test with the unpatched 3.5 tonight if that would be > of interest. Yes, this can help. > Best, > > -Nikolaus >