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