|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Re: [PATCH 0 of 6] dm-userspace xen integrationpatches
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|