From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36386) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0YnB-00022F-Mn for qemu-devel@nongnu.org; Mon, 05 Sep 2011 09:00:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0YnA-000665-Iy for qemu-devel@nongnu.org; Mon, 05 Sep 2011 09:00:49 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2171) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0YnA-00065x-Ad for qemu-devel@nongnu.org; Mon, 05 Sep 2011 09:00:48 -0400 Message-ID: <4E64C8AF.7040506@redhat.com> Date: Mon, 05 Sep 2011 15:03:43 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <20110901132755.GG14462@redhat.com> <20110901142735.GI14462@redhat.com> <20110901155620.GB11219@lst.de> In-Reply-To: <20110901155620.GB11219@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] QEMU online guest disk resize wrt host block devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christoph Hellwig Cc: qemu-devel@nongnu.org Am 01.09.2011 17:56, schrieb Christoph Hellwig: > On Thu, Sep 01, 2011 at 03:27:35PM +0100, Daniel P. Berrange wrote: >> One other question too, when creating a qcow2 image via 'qemu-img create' >> you can specify a 'prealloc' option to require metadata to be allocated >> at time of creation. >> >> Should we have the same control at time of resize too. If the app had >> originally created the qcow2 image with preallocated metadata, then >> I'd expect they want to pre-allocate metadata when extending it too, >> or is there no additional metadata allocation required when extending >> an image ? > > Sounds reasonable. Keving, is there a sane way to implement this? Implementing the functionality itself shouldn't be a big problem. The big question is what the right interface would look like. We have driver specific preallocation options, so we would end up with something like this: bdrv_truncate(bs, int64_t size, char* prealloc_mode). Not exactly nice. And is preallocation the only thing or would we need to pass a whole option list like for image creation? Of course, if this is a real requirement and not only a random thought, we can always introduce a specific flag for the current use case and add the generic thing only later when we have thought a bit more about it. Kevin