From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MLy86-0005Kz-6k for qemu-devel@nongnu.org; Wed, 01 Jul 2009 07:37:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MLy81-0005Bm-Ij for qemu-devel@nongnu.org; Wed, 01 Jul 2009 07:37:33 -0400 Received: from [199.232.76.173] (port=54854 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MLy81-0005BW-Ef for qemu-devel@nongnu.org; Wed, 01 Jul 2009 07:37:29 -0400 Received: from verein.lst.de ([213.95.11.210]:36296) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1MLy80-0000Lg-St for qemu-devel@nongnu.org; Wed, 01 Jul 2009 07:37:29 -0400 Date: Wed, 1 Jul 2009 13:37:26 +0200 From: Christoph Hellwig Subject: Re: [Qemu-devel] [PATCH] block-raw: Allow pread beyond the end of growable images Message-ID: <20090701113726.GD10455@lst.de> References: <1246038684-3702-1-git-send-email-kwolf@redhat.com> <20090630180940.GA4205@lst.de> <4A4B1238.8060302@redhat.com> <20090701085612.GA3564@lst.de> <4A4B2777.3050303@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A4B2777.3050303@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Christoph Hellwig , qemu-devel@nongnu.org On Wed, Jul 01, 2009 at 11:08:07AM +0200, Kevin Wolf wrote: > raw-win32 is actually a good question, I haven't tested that one. I > think nbd is used as a protocol rather than the format. qcow1/2 should > work, don't know for other formats like VMDK. > > What is biting us here is that nobody has ever specified what the block > driver functions are supposed to do. They exist because they are in the > struct, their parameters have names that give a rough idea about their > meaning and that's it. Who cares about special cases? > > That said, while implementing the the fix in bdrv_pwrite is going to be > ugly, we could do it in bdrv_read. Maybe this is the best approach. I have looked a bit at this area and it's even uglier than I expected. First problem is our use of the growable flag - it's overloaded for two different purposes: First we use it to allow growing files if they are protocols and opened through bdrv_file_open. Which already seems broken for host devices, but I'll need to test it. Second inside qcow2 it allows reading/writing past any image internally if bdrv_pwrite/bdrv_pread are called via qcow_put_buffer/qcow_get_buffer. I think we'd be much more future-proof if we make these flags to aio_read/aio_write to allow writing past the image size. Also none of this currently is easily testable as we don't expose the growable flag through qemu-io. And last not least I really hate how we tie up writing the VM metadata into the block/image code. I think we should also allow writing it into an external file with no ties to the image to allow offline migration or savevm even on a plain file or more important LVM volume.