On Fri, Sep 05, 2014 at 12:45:27PM -0400, Xingbo Wu wrote: > On Fri, Sep 5, 2014 at 6:02 AM, Stefan Hajnoczi <stefa...@gmail.com> 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
pgpIJ9BQ9KouC.pgp
Description: PGP signature
