Re: [Qemu-devel] [Qemu-block] [PATCH 03/17] spec: add qcow2-dirty-bitmaps specification

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2180 bytes --]

On 10/09/2015 11:07 AM, Max Reitz wrote:

> 
> Except maybe the last bit, because "512 byte sector" basically is
> meaningless when talking about a qcow2 file (which works in terms of
> clusters),

At KVM Forum, Kevin was mentioning an idea of adding an incompatible
feature to qcow2 that would let it track per-sector dirty/zero/backing
information within a cluster (things would still be allocated by
cluster, but you could get fine-grained COW and other perks), by having
the feature bit turn on an alternative L2 table entry representation
that occupies more than 64 bits.  If that happens, then qcow2 would have
a bit more per-sector smarts in addition to its existing per-cluster
focus.  But not something that should hold up this discussion.

>> We could store filenames, but networked devices and distributed
>> filesystems may have interesting relative pathnames that will not remain
>> reliable once the .qcow2 file is shuffled around or migrated, so storing
>> path-name references seems like a losing battle here, too. Maybe we only
>> have a file descriptor and no name at all -- what do we write for the
>> "global identifier that uniquely identifies the data we belong to"? Is
>> it even possible?
> 
> I'd be fine with filenames. It works reasonably well for backing files,
> and it's basically the same problem there.

Filenames with the escape clause of json:{...} pseudo-filenames
(matching what we already allow for complex backing files) is fine by me.

>> Does anybody else have strong feelings on where we should go from here?
>>
>> (A) Argue with Max and push for qcow2-as-container
> 
> :-)
> 
>> (B) Use qcow2 for self-reference bitmaps only, use an external format
>> for formats that do not support .bitmap_load or .bitmap_store
>> (C) Forget about the qcow2 extension entirely, use only the new external
>> format
>> (D) Something else?
>>
>> My vote is for (B),
> 
> Sounds good to me.

I'm also leaning towards (B) at the moment, but could possibly still be
swayed by persuasive arguments.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]