[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-discuss] [Qemu-devel] write operations during read

From: Kevin Wolf
Subject: Re: [Qemu-discuss] [Qemu-devel] write operations during read
Date: Thu, 16 Jul 2015 12:00:44 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Hi Gleb,

Am 15.07.2015 um 13:04 hat Gleb Stepanov geschrieben:
>    We are testing disk I/O perfomance using fio tool. I've measured
> performance on qcow2 image mounted to nb0 device. I run tests and
> launch iostat -x 1 command to browse I/O operations. Test consists of
> sequential read operations with 1 MB size. I've get following output.
> Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s
> sda               0.00     5.00    0.00  677.00     0.00 22812.00
> sdb               0.00     0.00    0.00  545.00     0.00     0.00
> dm-0              0.00     0.00    0.00  674.00     0.00 22784.00
> dm-1              0.00     0.00    0.00    7.00     0.00    28.00
> dm-2              0.00     0.00    0.00    0.00     0.00     0.00
> nb0               0.00     0.00  432.00  182.00 55296.00 23296.00
> So, reading produce a lot of write operations. What is the reason why
> these write operations occured?

Unfortunately you didn't include your qemu command line and didn't
describe in detail what your test setup looked like, so I'll have to
take a guess.

Read requests never cause writes. However, you wrote 55 MB to the image
before running the test. Did you make sure that this data was already
flushed to the disk before starting your benchmark? If it was only
sitting in the kernel page cache, the kernel can decide to write it out
at any point.

> How to determina block size that qemu operates , because if i've
> writtien 55 mb with 1 mb blocks
> i should get 55 operations instead of 432.

If you didn't use O_DIRECT in the benchmark, chances are that the guest
kernel issues requests smaller than 1 MB to qemu.

Be aware that you might get a few metadata reads in the guest
filesystem, the qcow2 and the host filesystem layer, so slightly more
than 55 requests is expected. Each layer may also have to split requests
if the data is stored fragmented.

Also, did you make sure that no processes other than fio access the


reply via email to

[Prev in Thread] Current Thread [Next in Thread]