qemu-devel
[Top][All Lists]
Advanced

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

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [6397] Vectored block device API (Avi Kivity)
Date: Mon, 26 Jan 2009 14:48:46 -0600
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

Gerd Hoffmann wrote:
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?

Avi is on vacation this week but my understanding is that he'll be submitting patches shortly after he gets back.

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 ?).

Internally, qcow, qcow2, etc. use the block API to access the disk formats. These accesses are not always sector aligned.

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.

I agree with this on principle, but making all of the entry points thread safe is a fair bit of work. Recall that we don't use threads on every platform so we need to take that into account too.

Regards,

Anthony Liguori

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

cheers,
  Gerd







reply via email to

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