From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LRx6G-0008JC-UO for qemu-devel@nongnu.org; Tue, 27 Jan 2009 18:12:09 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LRx6E-0008Ic-MF for qemu-devel@nongnu.org; Tue, 27 Jan 2009 18:12:07 -0500 Received: from [199.232.76.173] (port=52149 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LRx6E-0008IY-Jd for qemu-devel@nongnu.org; Tue, 27 Jan 2009 18:12:06 -0500 Received: from mx2.redhat.com ([66.187.237.31]:44131) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LRx6E-0000Jd-7D for qemu-devel@nongnu.org; Tue, 27 Jan 2009 18:12:06 -0500 Message-ID: <497F94BE.7060708@redhat.com> Date: Wed, 28 Jan 2009 01:11:58 +0200 From: Uri Lublin MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/2] qemu block changes: keep backing file format v2 References: <1232995199-12086-1-git-send-email-uril@redhat.com> <20090126215654.GB9296@shareable.org> <497F0ACF.9040006@redhat.com> <497F80B9.7070007@codemonkey.ws> In-Reply-To: <497F80B9.7070007@codemonkey.ws> 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 Anthony Liguori wrote: > Uri Lublin wrote: >> Jamie Lokier wrote: >>> Uri Lublin wrote: >>>> I call "hidden image format" to the following format of a backing >>>> file name: >>>> "name\0format". Although it can be considered a hack, that's an easy >>>> way to support old images with new qemu as well as old qemu with new >>>> images >>>> (in which case probing would be done), without changing the qcow2 >>>> header. >>> ... >>>> Changes from v1: use "name\0format" instead of "fmt:FMT:name" >>> >>> Do you think there will be any other information added in future, >>> while wanting to remain compatible with old qemus (i.e. without >>> changing the qcow2 header)? >>> >>> If so, "name\0format=FMT", and stop at the second \0 if there is one, >>> something like that? >>> >>> -- Jamie >> >> I think you'd always want to keep the format of your backing file, so >> as long as >> you keep the order of options fixed, it's safe (meaning we can add >> more options following the format, and there is no need to parse it). >> >> If we are thinking about ways to extend the simple "name\0options" >> format, > > How about just extending the qcow2 header instead of playing ugly games > with the backing_file field? > Would that be considered qcow3 ? Shahar's extensions are following in the qcow2 header (without breaking existing images). I forgot to mention they are only implemented for qcow2 images. Currently backing files are being opened in block.c:bdrv_open2(). If we want to do something specific to qcow2 (with regards to the backing file format), we'll need to leave bs->backing_file empty and open the backing file from block-qcow2.c:qcow_open(). Or we can add a backing_format field to struct BlockDriverState. Regards, Uri. >> Shahar Frank wrote a better, more extensible implementation, which >> saves image options as extensions following the qcow2-header. The >> options are saved in a binary format similar to the header. Each >> option has a little header of its own which includes magic(==type) and >> len. >> >> We (Shahar) also implemented a zero-cluster (aka zero-dedup) and would >> like, >> in the future, to keep the offset of that cluster. >> >> If such an approach is acceptable, I can work on a patch implementing >> it (rebase and improve a bit Shahar's implementation). >> >> Thanks, >> Uri.