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

[Chunqiang Tang]

> >> 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. 

> Maybe I missed it, but in the WCE=0 mode, is it really possible to avoid 

> the writes for the refcount table?

Yes, this is indeed achieved in FVD, with zero writes to the refcount 
table on the fast path. See details in the other email I am going to send 
out soon.

Regards,
ChunQiang (CQ) Tang
Homepage: http://www.research.ibm.com/people/c/ctang