Dan Smith wrote: > Comments? 1.) Is there any technically convincing reason why the qcow thing must be an integral part of the CoW target? I'm thinking that it's possibly cleaner to implement a device-mapper target that presents a block device of a custom size to upper layers, while actually storing data in a qcow file, regular sparse file, or what not. For the sake of discussion, let's call this dm extension 'dm-autogrow'. What you're trying to do could then be accomplished by layering dm-snapshot on top of dm-autogrow. It requires a bit more scripting magic, but in the end the implementation might turn out to be simpler, and you get to reuse dm-snapshot. A dm-autogrow target is potentially useful for other things. There are various applications that would like to read a qcow file as a block device, for example. Perhaps the QEMU folks would be helpful wrt. the implementation stuff, since QEMU could potentially use it too. That said, I feel that 'qcow' is a bit of a misnomer. It's not like QEMU is actually copying any blocks anywhere is it? It's a file that grows automatically, but AFAIK QEMU has absolutely no snapshot / CoW support. With the above in mind, and assuming that you want the qcow image as the write target, I'm unsure why it would even be useful to use a qcow image in particular. It's not like qemu will be able to make any sense of the qcow file afterwards, since it will only contain half a filesystem... or am I completely wrong here? 2.) A couple of things I would personally like to see wrt. Xen and CoW. a.) Avoid write reordering (= avoid breaking journal filesystems in Xen vms). b.) When an entire block of zeros is written, nuke it from the qcow image or "sparsify" the block in the underlying sparse file. Point b) requires a patch to guest domains so that the filesystem zero released blocks, but that already exists for ext3, I think. (An alternative approach to that would be to make a target in between the guest and the CoW device that understands the ext3 filesystem. It could catch when ext3 writes to the list of free filesystem blocks and zero those blocks..) ... too tired to come up with anything else right now :-). -- dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel