From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNaS7-0003aB-EM for qemu-devel@nongnu.org; Mon, 28 Jul 2008 17:40:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNaS5-0003ZS-G7 for qemu-devel@nongnu.org; Mon, 28 Jul 2008 17:40:22 -0400 Received: from [199.232.76.173] (port=44247 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNaS4-0003ZH-VA for qemu-devel@nongnu.org; Mon, 28 Jul 2008 17:40:21 -0400 Received: from py-out-1112.google.com ([64.233.166.176]:21643) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KNaS4-00018O-EZ for qemu-devel@nongnu.org; Mon, 28 Jul 2008 17:40:20 -0400 Received: by py-out-1112.google.com with SMTP id p76so3497573pyb.10 for ; Mon, 28 Jul 2008 14:40:20 -0700 (PDT) Message-ID: <488E3CA2.2000502@codemonkey.ws> Date: Mon, 28 Jul 2008 16:39:46 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] qcow3 - arbitrary metadata References: <488E2752.7030008@codemonkey.ws> <488E3116.9030809@codemonkey.ws> <488E3750.8010401@codemonkey.ws> In-Reply-To: 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 Nathaniel McCallum wrote: > On Mon, Jul 28, 2008 at 5:17 PM, Anthony Liguori > > wrote: > > Nathaniel McCallum wrote: > > On Mon, Jul 28, 2008 at 4:50 PM, Anthony Liguori > > >> > wrote: > > Something that would be pretty interesting, but also terribly > hacky, would be to have an option that would allow one to use a > disk with an offset. For instance: > > qemu-system-x86_64 -drive file=foo.img,offset=4096,if=ide > > > I assume this technique is more "mergable" > > > Than forking the qcow format? Definitely, although I'm not > convinced there isn't a better way to do it that is even less hacky. > > > I'd love to know what that other option could be. Adding an offset > option is going to touch a lot of files... Actually, it wouldn't. You just need to modify the RAW block driver to add an offset to any of the operations that would seek within the file. There's no clear way to pass individual arguments to a particular block format though so that would make it somewhat hairy. Regards, Anthony Liguori