[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Re: [PATCH 0 of 6] dm-userspace xen integrationpatches
JC> Your new CoW driver, however doesn't handle allocation, it just JC> assumes a CoW volume that's as big as the original disk Correct, it does not do sparse allocation. Sparse allocation does not make any sense on a fixed-size block device. Note that it has nothing to do with how the rest of the dm-userspace/cowd system works. When using the prototype qcow plugin to cowd, sparse allocation is performed as you would expect. JC> and uses a bitmap to optimize lookups. It does not use a bitmap to optimize lookups, it uses a bitmap as the metadata to record which blocks have been mapped. It also determines where the block is located in the CoW volume, as this can be determined from the block size and the bit number. JC> Given that you seem to be assuming that the block device is JC> providing sparse allocation and dynamic disk resizing for you, No, I'm not assuming this. With this current format plugin, we are just assuming a fully-allocated block device (such as a LVM, or a simple iSCSI device). JC> isn't it likely that such devices would already provide low-level JC> support for CoW and disk snapshotting? Some do, but plenty do not. However, being able to do snapshots, CoW, rollback, etc while easily synchronizing with other pieces of Xen is something that will be simpler with dm-userspace than with a hardware device. It also allows us to provide the same advanced features, no matter what device we are working on top of, and independent of whether or not it supports them. JC> Qcow provides both sparse support and CoW functionality. Sparse allocation and control of block devices (i.e. growing an LVM as we need it for a growing CoW storage) is definitely something that is on our radar. We are just not there yet. I should mention here that I am not fighting for a format here. The plugin that is the default in cowd right now (dscow) implements a very simple format geared at speed and simplicity. It has limitations and we understand that. It is not intended to be the CoW format of the future :) JC> What's the policy on metadata writes - are metadata writes JC> synchronised with the acknowledgement of block IO requests? Yes. Ian asked for this the last time we posted our code. We have worked hard to implement this ability in dm-userspace/cowd between the time we posted our original version and our recent post. While the normal persistent domain case definitely needs this to be "correct", there are other usage models for virtual machines that do not necessarily need to have a persistent disk store. We are able to disable the metadata syncing (and the metadata writing altogether if desired) and regain a lot of speed. -- Dan Smith IBM Linux Technology Center Open Hypervisor Team email: danms@xxxxxxxxxx Attachment:
pgpiQ9Pro2QL1.pgp _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |