From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K3qAY-0002kC-9G for qemu-devel@nongnu.org; Wed, 04 Jun 2008 06:24:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K3qAX-0002j1-9m for qemu-devel@nongnu.org; Wed, 04 Jun 2008 06:24:37 -0400 Received: from [199.232.76.173] (port=34754 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K3qAX-0002is-3N for qemu-devel@nongnu.org; Wed, 04 Jun 2008 06:24:37 -0400 Received: from rv-out-0708.google.com ([209.85.198.242]:57022) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1K3qAW-0002Xn-Sm for qemu-devel@nongnu.org; Wed, 04 Jun 2008 06:24:37 -0400 Received: by rv-out-0708.google.com with SMTP id f25so25024rvb.22 for ; Wed, 04 Jun 2008 03:24:35 -0700 (PDT) Message-ID: Date: Wed, 4 Jun 2008 03:24:35 -0700 From: "Marc Bevand" Subject: Re: [Qemu-devel] [PATCH 0/2] Update documentation for qemu-img + add new -B option In-Reply-To: <20080604073716.GA20295@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2c9e3f91af3dc46f86cdf5cf11d62512@foo> <20080604073716.GA20295@shareable.org> 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 On Wed, Jun 4, 2008 at 12:37 AM, Jamie Lokier wrote: > > I wonder if a useful option would be to be able to create an image > relative to a _different_ base image. I.e. I see what you mean. qemu-img could compare the content of each sector in images A and B (no matter what A is based on) and infer and image A' (based on B) equivalent to A. I wonder too if it would be _that_ useful in real-world scenarios. > Another thing, which might be easier and more useful, would be > instantiating zeros in the source image into holes in the relative > image. To save space, after lots of changes on the virtual hard disk > and some zeroing. (Microsoft has a tool to do this with Virtual PC). Actually "qemu-img convert A B" already does this: zeros in A are converted to holes in B (more precisely: real holes if B is a raw image, or undefined clusters if the qcow/qcow2 case). B in this example would be a flat image. If you wanted to do the same thing with B a relative image, the qcow/qcow2 format would need to be extended because there is currently no defined way to efficiently represent zero'd clusters in relative images. (Or actually now that I think about it maybe we could represent zero'd clusters as if they were compressed even when compression is disabled.) I am curious, does Virtual PC support relative aka copy-on-write images ? -- Marc Bevand