QCOW2 vs QROW2 Disks

[Jorge Fábregas]

Hi there,

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)?

Thanks in advance,
Jorge

[Cole Robinson]

On 10/27/2012 04:37 PM, Jorge Fábregas wrote:
>  Hi there,
>  
>  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)?
>   
Probably a question for qemu-devel, but I think the qcow name was derived from
the cow format from user mode linux. The cow format's primary feature was
essentially qcow's backing_file file feature, so the name is likely derived
from that, and not necessarily qcow2's snapshotting abilities.

- Cole

[Kashyap Chamarthy]

On 10/28/2012 02:07 AM, Jorge Fábregas wrote:
>  Hi there,
>  
>  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)? 
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

>  
>  Thanks in advance,
>  Jorge
>  _______________________________________________
>  virt mailing list
>  virt(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/virt
>

[Kashyap Chamarthy]

On 10/29/2012 09:54 AM, Kashyap Chamarthy wrote:
>  On 10/28/2012 02:07 AM, Jorge Fábregas wrote:
> > Hi there,
> >
> > 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)?
>  
>  The COW part /is/ related to  external disk snapshots: 
Now, that I re-read your question (after taking coffee), I didn't answer your question
:)

I think, COW means -- on 'write', modify the 'copy'(which is the
overlay).

/kashyap

>  
>  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
>  
> >
> > Thanks in advance,
> > Jorge
> > _______________________________________________
> > virt mailing list
> > virt(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/virt
> >
>  
>  _______________________________________________
>  virt mailing list
>  virt(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/virt
>

[Kevin Wolf]

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

QCOW2 vs QROW2 Disks [SOLVED]

[Jorge Fábregas]

On 10/29/2012 04:36 AM, Kevin Wolf wrote:
>  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. 
Eureka!  Thanks Kevin!  Now the COW part makes total sense!  I searched
the web for this (prior to sending this question) and believe me, I
couldn't find it this relationship (the name and how the cluster
handling works).

Many many thanks!

-- 
Jorge