From: Gerd Hoffmann <kraxel@redhat.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [6397] Vectored block device API (Avi Kivity)
Date: Mon, 26 Jan 2009 16:13:34 +0100 [thread overview]
Message-ID: <497DD31E.8000700@redhat.com> (raw)
In-Reply-To: <E1LQ2to-0003LM-Kf@cvs.savannah.gnu.org>
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
next prev parent reply other threads:[~2009-01-26 17:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-22 16:59 [Qemu-devel] [6397] Vectored block device API (Avi Kivity) Anthony Liguori
2009-01-26 15:13 ` Gerd Hoffmann [this message]
2009-01-26 20:48 ` Anthony Liguori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=497DD31E.8000700@redhat.com \
--to=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.