[linux-lvm] Why I/O test on LVM image (KVM) works suspicious compared to raw file image via varmail.f in Filebench benchmark?

[Zhang Zhaoning]

Here I compare I/O performance on LVM image and raw file image (directly
generated by Linux bash '*dd*'), with the virtual machine hypervisor KVM,
guest and host are both CentOS 6.2, and the guest has 1 CPU, 8G memory.
I use Filebench (filebench-1.4.9.1) as one of the benchmark, I use
varmail.f oltp.f fileserver.f webserver.f (unmodified from the workload in
the packet) to test the macro-benchmark.

The test of fileserver.f and webserver.f show that the LVM image and raw
file image performs the similar result.
But the varmail.f shows that LVM outperforms than the raw file by several
times, and the table below shows the data:


fileserver.f (*KB/s*) oltp.f
(*KB/s*) varmail.f
(*KB/s*) webserver.f
(*KB/s*)  rawfile 17318.4 76.8 256 8576  lvm 16921.6 140.8 780.8 8448

Thus, I test varmail.f by changing different parameters, and the table
below shows the data:

  lvm(a)
(*KB/s*) rawfile(b)
(*KB/s*) a/b  varmail.iosize-.f 742.4 179.2 4.142857  varmail.iosize+.f
742.4 179.2 4.142857  varmail.meanappendsize-.f 51.2 25.6 2
varmail.meanappendsize+.f 2278.4 985.6 2.311688  varmail.meandirwidth-.f
729.6 179.2 4.071429  varmail.meandirwidth+.f 742.4 166.4 4.461538
varmail.meanfilesize-.f 729.6 179.2 4.071429  varmail.meanfilesize+.f 742.4
179.2 4.142857  varmail.nfiles-.f 819.2 192 4.266667  varmail.nfiles+.f 640
179.2 3.571429  varmail.nthreads-.f 486.4 153.6 3.166667
varmail.nthreads+.f 1190.4 230.4 5.166667  varmail.nofsync.f 6259.2 6272
0.997959

varmail.nofsync.f is remove these two lines:
*    flowop fsync name=fsyncfile2,fd=1*
*    flowop fsync name=fsyncfile3,fd=1*

So, the initiator is *fsync*, which is not existed in fileserver.f and
webserver.f, and oltp.f has a dsync.
I think the function of the fsync is to force data from OS memory to disk,
but how does it influence the LVM virtual I/O performance?

Could anybody told me what cause this?

Thanks very much.

-- 
Thank you!

Brian Zhaoning Zhang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-lvm/attachments/20130301/fbe3ef72/attachment.htm>