From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LRYOG-0002CR-L2 for qemu-devel@nongnu.org; Mon, 26 Jan 2009 15:49:04 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LRYOF-0002Bu-Pm for qemu-devel@nongnu.org; Mon, 26 Jan 2009 15:49:04 -0500 Received: from [199.232.76.173] (port=38436 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LRYOF-0002Br-C1 for qemu-devel@nongnu.org; Mon, 26 Jan 2009 15:49:03 -0500 Received: from qw-out-1920.google.com ([74.125.92.144]:24309) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LRYOE-0001QL-UO for qemu-devel@nongnu.org; Mon, 26 Jan 2009 15:49:03 -0500 Received: by qw-out-1920.google.com with SMTP id 5so1185386qwc.4 for ; Mon, 26 Jan 2009 12:49:01 -0800 (PST) Message-ID: <497E21AE.7040202@codemonkey.ws> Date: Mon, 26 Jan 2009 14:48:46 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [6397] Vectored block device API (Avi Kivity) References: <497DD31E.8000700@redhat.com> In-Reply-To: <497DD31E.8000700@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 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 > > >