[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Chunqiang Tang
Subject: Re: [Qemu-devel] Re: Strategic decision: COW format
Date: Mon, 14 Mar 2011 11:04:35 -0400

> >> The file system can keep a lot of these things around pretty easily 
> >> with your proposal, it seems like there can only be one.  If you 
> >> 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 

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]