This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH 0 of 6] dm-userspace xen integrationpatches

To: Dan Smith <danms@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH 0 of 6] dm-userspace xen integrationpatches
From: Julian Chesterfield <jac90@xxxxxxxxx>
Date: Wed, 30 Aug 2006 00:47:06 +0100
Cc: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>, Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 29 Aug 2006 16:48:49 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <m3mz9n8uit.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D5725AC@xxxxxxxxxxxxxxxxxxxxxxxxxxx> <m3mz9n8uit.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 29 Aug 2006, at 15:51, Dan Smith wrote:

IP> What data structure / format are you using for storing the CoW
IP> data?

Currently, I've got a really simple format that just forms an identity
mapping by using a bitmap. The first block (or blocks) on the
destination is reserved for metadata. After that, if bit X is set,
then block X is located in block X+1 in the cow space.

You indicated recently that you are focused on block- as opposed to file-backed virtual disks. Your new CoW driver, however doesn't handle allocation, it just assumes a CoW volume that's as big as the original disk and uses a bitmap to optimize lookups. Given that you seem to be assuming that the block device is providing sparse allocation and dynamic disk resizing for you, isn't it likely that such devices would already provide low-level support for CoW and disk snapshotting? Qcow provides both sparse support and CoW functionality.

It's fast, it
doesn't waste space, and it's easy to predict a mapping and flush it
later to avoid metadata reservations.

What's the policy on metadata writes - are metadata writes synchronised with the acknowledgement of block IO requests?

- Julian

Xen-devel mailing list