Re: [Qemu-devel] [6397] Vectored block device API (Avi Kivity)

[Gerd Hoffmann]

Anthony Liguori wrote:
> For block devices, this translates to vectored I/O.  This patch implements
> an aynchronous vectored interface for the qemu block devices.  At the moment
> all I/O is bounced and submitted through the non-vectored API; in the future
> we will convert block devices to natively support vectored I/O wherever
> possible.

Any plan for this?

Current state is this:  BlockDriver provides *three* ways to do I/O.

#1 is brdv_{read,write}, operating on sectors.
#2 is bdrv_aio_{read,write}, operation on sectors too.
#3 is brdv_{pread,pwrite}, operating on bytes.

All block drivers implement #1.
Most block drivers implement only #1.
#2 is implemented by qcow, qcow2, raw (including host_device).
#3 is implemented by raw (+hostdevice) only.

We can't kill #1 for the time being.

Not sure what the motivation for #3 is (O_DIRECT ?).  Is that actually
useful for something?  Can we drop it maybe?  Block I/O is sector
oriented after all, so I'm not sure what the motivation for a
byte-oriented interface is in the first place ...

#2 is the candidate to be transformed into a vectored API.  Given the
plan is to implement aio using threads:  I think the block driver
doesn't need to know anything about aio.  It should provide read/write
methods which are (a) vectored and (b) thread-safe.

For raw this is trivial:  Use preadv(), done.

For qcow2 this is a bit more difficuilt.  Metadata updating obviously
requires some locking.  Probably lookups too (I'm not familiar with the
on-disk format and driver internals).  The actual data transfer should
be doable unlocked I think.

The interface could look like this:

    int (*bdrv_read)(BlockDriverState *bs, QEMUIOVector *qiov,
                     int64_t sector_num);
    int (*bdrv_write)(BlockDriverState *bs, QEMUIOVector *qiov,
                      int64_t sector_num);

All the aio magic can live in the block layer then, well hidden from the
block drivers.

Comments on this?  Especially from people knowing qcow2 better that I do?

cheers,
  Gerd