On 10/28/2012 02:07 AM, Jorge Fábregas wrote: The COW part /is/ related to external disk snapshots: Whenever you take external disk-only snapshot, the current disk image in use is marked read-only(while serving as a backing file for the rest of the snapshots taken), and a new QCOW2 overlay is created to track the new 'writes'(or delta) from there on. It's worth noting that, the base image can be RAW or QCOW2, but the snapshots(or overlays) are always QCOW2. (Note that - read-only doesn't mean, file-system permissions, but 'qemu' opens the disk read-only.) See if this are helpful : http://kashyapc.wordpress.com/2012/09/14/externaland-live-snapshots-with-... http://kashyapc.wordpress.com/2012/10/04/creating-rapid-thin-provisioned-... /kashyap

Hi Jorge, Am 27.10.2012 22:37, schrieb Jorge Fábregas: Let's take a simple example, a fully allocated backing file, and a completely empty, fresh snapshot: $ qemu-img create -f qcow2 base.qcow2 1M $ qemu-io -c 'write -P 123 0 1M' base.qcow2 $ qemu-img create -f qcow2 -b base.qcow2 sn1.qcow2 Now imagine we're doing a read, starting at byte 0, with a length of 4k. What happens is that the qcow2 driver looks at the metadata of sn1.qcow2 and sees that the first cluster isn't allocated there. So the request is made against base.qcow2 - "redirect on read", if you will. Now the same thing with a write: Obviously there is no redirect here, the backing file is the read-only snapshot, you don't want to write there. We just write into sn1.qcow2, after allocating a fresh cluster. And this is where the copy occurs: qcow2 is organised in clusters, in our example with the default 64k cluster size. A cluster can only be allocated or unallocated as a whole. Now that we're allocating 64k in sn1.qcow2, but have only 4k to write from our write request, the remaining 60k must be copied from the backing file so that reading them gives the same result as before. Kevin