From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LRVVH-0001rA-0s for qemu-devel@nongnu.org; Mon, 26 Jan 2009 12:44:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LRVVE-0001l3-G6 for qemu-devel@nongnu.org; Mon, 26 Jan 2009 12:44:05 -0500 Received: from [199.232.76.173] (port=33582 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LRVVE-0001ke-9b for qemu-devel@nongnu.org; Mon, 26 Jan 2009 12:44:04 -0500 Received: from mx20.gnu.org ([199.232.41.8]:51900) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LRV4B-0004VU-Dv for qemu-devel@nongnu.org; Mon, 26 Jan 2009 12:16:07 -0500 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LRTBk-0003U9-FG for qemu-devel@nongnu.org; Mon, 26 Jan 2009 10:15:48 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n0QFDlfH007976 for ; Mon, 26 Jan 2009 10:13:47 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n0QFDl1c016471 for ; Mon, 26 Jan 2009 10:13:47 -0500 Received: from zweiblum.travel.kraxel.org (vpn-10-110.str.redhat.com [10.32.10.110]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n0QFDequ026434 for ; Mon, 26 Jan 2009 10:13:44 -0500 Message-ID: <497DD31E.8000700@redhat.com> Date: Mon, 26 Jan 2009 16:13:34 +0100 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [6397] Vectored block device API (Avi Kivity) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.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