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 <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 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 > -- 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
