Re: [Qemu-devel] I/O parallelism on QCOW2

[Stefan Hajnoczi]

On Fri, Sep 05, 2014 at 12:45:27PM -0400, Xingbo Wu wrote:
> On Fri, Sep 5, 2014 at 6:02 AM, Stefan Hajnoczi <address@hidden> wrote:
> 
> > On Thu, Sep 04, 2014 at 12:32:12PM -0400, Xingbo Wu wrote:
> > >   After running a 16-thread sync-random-write test against qcow2, It is
> > > observed that QCOW2 seems to be serializing all its metadata-related
> > writes.
> > >  If qcow2 is designed to do this,* then what is the concern?* What would
> > go
> > > wrong if this ordering is relaxed?
> >
> > How do you know that serializing part of the write request is a
> > significant bottleneck?
> >
> > Please post your benchmark results with raw, qed, and qcow2 handling 1-,
> > 8-, and 16-threads of I/O (or whatever similar benchmarks you have run).
> >
> > The bottleneck may actually be something else, so please share your
> > benchmark configuration and results.
> >
> >
> Here is the fio job file:
> ----j1.fio:
> [j1]
> direct=1
> ioengine=psync
> thread
> fdatasync=1
> runtime=300
> numjobs=$NJ
> # filename=/dev/sd? for raw disk
> filename=/dev/nbd0
> rw=write
> bs=64k
> offset_increment=1G
> ----EOF

Aha!

The job file has fdatasync=1 so fio will issue fdatasync(2) after every
I/O.  If the qcow2 file is freshly created no clusters are allocated yet
so every write is an allocating write, in other words each I/O requests
causes a flush_to_os() and writes out metadata.

So even numjobs=1 will be significantly slower with qcow2 than raw!
Serializing write requests is not the main problem here, metadata
updates are.

You can check this by running dd if=/dev/zero of=/dev/... bs=1M; sync in
the guest before running the benchmark.  The qcow2 results should now be
very close to raw.

Stefan

pgplTSQT6O6tM.pgp
Description: PGP signature