Re: [Qemu-devel] Re: Strategic decision: COW format

[Kevin Wolf <kwolf@redhat.com>]

Am 14.03.2011 15:47, schrieb Anthony Liguori:
> On 03/14/2011 09:15 AM, Kevin Wolf wrote:
>>> The file system can keep a lot of these things around pretty easily but
>>> with your proposal, it seems like there can only be one.  If you support
>>> many of them, I think you'll degenerate to something as complex as a
>>> reference count table.
>> IIUC, he already uses a refcount table.
> 
> Well, he needs a separate mechanism to make trim/discard work, but for 
> the snapshot discussion, a reference count table is avoided.
> 
> The bitmap only covers whether the guest has accessed a block or not.  
> Then there is a separate table that maps guest offsets to offsets within 
> the file.
> 
> I haven't thought hard about it, but my guess is that there is an 
> ordering constraint between these two pieces of metadata which is why 
> the journal is necessary.  I get worried about the complexity of a 
> journal even more than a reference count table.

Honestly I think that a journal is a good idea that we'll want to
implement in the long run.

There are people who aren't really happy about the dirty flag + fsck
approach, and there are people who are concerned about cluster leaks
without fsck. Both problems should be solved with a journal.

Compared to other questions in the discussio, I think it's only a
nice-to-have addition, though.

>>   Actually, I think that a
>> refcount table is a requirement to provide the interesting properties
>> that internal snapshots have (see my other mail).
> 
> Well the trick here AFAICT is that you're basically storing external 
> snapshots internally.  So it's sort of like a bunch of FVD formats 
> embedded into a single image.

CQ, can you please clarify? From your description, Anthony seems to
understand something completely different than I do.

Are its characteristics more like qcow2's internal snapshots (which is
what I understand) or more like external snapshots (which is what
Anthony seems to understand).

>> Refcount tables aren't a very complex thing either. In fact, it makes a
>> format much simpler to have one concept like refcount tables instead of
>> adding another different mechanism for each new feature that would be
>> natural with refcount tables.
> 
> I think it's a reasonable design goal to minimize any metadata updates 
> in the fast path.  If we can write 1 piece of metadata verses writing 2, 
> then it's worth exploring IMHO.
> 
>> The only problem with them is that they are metadata that must be
>> updated. However, I think we have discussed enough how to avoid the
>> greatest part of that cost.
> 
> Maybe I missed it, but in the WCE=0 mode, is it really possible to avoid 
> the writes for the refcount table?

Protected by a dirty flag (and/or a journal), sure. I mean, wasn't that
the whole point of starting the qcow3 discussion?

Kevin