On 07/05/2012 10:08 AM, Pavel Emelyanov wrote: > On 07/05/2012 05:07 PM, Nikolaus Rath wrote: >> Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@xxxxxxxxxxxxxxxx> 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 can try the same test with the unpatched 3.5 tonight if that would be of interest. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
