From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [6397] Vectored block device API (Avi Kivity)
Date: Mon, 26 Jan 2009 14:48:46 -0600 [thread overview]
Message-ID: <497E21AE.7040202@codemonkey.ws> (raw)
In-Reply-To: <497DD31E.8000700@redhat.com>
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
>
>
>
prev parent reply other threads:[~2009-01-26 20:49 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
2009-01-26 20:48 ` Anthony Liguori [this message]
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=497E21AE.7040202@codemonkey.ws \
--to=anthony@codemonkey.ws \
--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.