Hi Jorge, Am 27.10.2012 22:37, schrieb Jorge Fábregas: > I'm just curious: Where does the "Copy on Write" (from QCOW) comes > from? Everything I've been reading regarding how snapshots work with > QEMU points to a "redirect on write" approach. Or is the COW part > related to some other internal mechanism (not related to snapshots)?
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 _______________________________________________ virt mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/virt
