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

[Stefan Hajnoczi]

On Mon, Mar 14, 2011 at 3:04 PM, Chunqiang Tang <address@hidden> 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.
>
> Kevin is right. FVD does have a refcount table. Sorry for causing
> confusion. I am going to send out a very detailed email which describes
> the operation steps in FVD, as Stefan requested.
>
>> 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.
>
> No, the journal is not necessary. Actually, a very old version of FVD
> worked without journal. Journal was later introduced as a performance
> enhancement.

I like the journal because it allows us to isolate metadata updates
into one specific area that can be scanned on image recovery.  If we
take the QED approach with the dirty bit then we have to scan all
L1/L2 tables.  The journal makes recovery more efficient than a full
consistency check.

Stefan