> From: Kevin Wolf [mailto:[email protected]] > Am 06.03.2019 um 10:37 hat Pavel Dovgalyuk geschrieben: > > > From: Kevin Wolf [mailto:[email protected]] > > > Am 06.03.2019 um 10:18 hat Pavel Dovgalyuk geschrieben: > > > > > Something like: > > > > > > > > > > -drive file=null-co://,if=none,id=null -device virtio-blk,drive=null > > > > > > > > And this drive should be destination of the copy operations, right? > > > > > > I don't know your exact benchmark, but this drive should be where the > > > high I/O rates are, yes. > > > > Ok. > > > > > For getting meaningful numbers, you should have I/O only on the fast > > > test disk (you're talking about a copy, where is source?), > > > > We used a qcow2 image as a source. > > So the source is going to slow down the I/O and you won't actually test > whether the possible maximum changes. > > > > you should > > > use direct I/O to get the page cache of the guest out of the way, and > > > you should make sure that multiple requests are issued in parallel. > > > > Is this possible, if we have only conventional HDDs? > > null-co:// doesn't access your disk at all, so if this is the only > virtual disk that has I/O, the conventional HDD doesn't hurt. But you're > right that you probably can't use your physical disk for high > performance benchmarks then. > > I'm going to suggest once more to use fio for storage testing. Actually, > maybe I can find the time to do this myself on my system, too.
Ok, I'll try it. > But anyway, I think it's good if you're at least aware that the test you > used so far was a low-performance test where any possible performance > degradations would be dwarved by both the slow physical disk and the > slow IDE interface to communicate with the guest (which also enforces to > have only one request at the same time). Pavel Dovgalyuk
