Re: [Qemu-devel] [RFC 0/7] qcow2: implement lazy refcounts optimization

[Stefan Hajnoczi]

On Mon, Jun 25, 2012 at 3:06 PM, Zhi Yong Wu <address@hidden> wrote:
> On Fri, Jun 22, 2012 at 11:08 PM, Stefan Hajnoczi
> <address@hidden> wrote:
>> This series aims to improve qcow2 performance with cache=writethrough and
>> cache=directsync.  In particular it reduces the impact of metadata updates 
>> for
> What does cache=directsync mean? what is the difference between them?

O_DIRECT + fdatasync()

Check the code if you want to compare/understand caching modes.

>> allocating writes.
>>
>> Allocating writes are expensive because they involve updating L2 tables and
>> refcount blocks.  In addition they can also cause L2 table allocation and
>> refcount block allocation but these remain unaffected by this optimization.
>>
>> The key insight is that refcounts are not required to access data in the 
>> image.
> Can you elaborate this? why?

The guest block address -> image file block address translation only
uses the L1/L2 tables.  Refcounts are used for allocation and
Copy-on-Write - not for read-only access.

>> This means that we can postpone refcount updates without violating the data
>> integrity guarantee that cache=writethrough and cache=directsync give.
>>
>> The trade-off for postponing refcount updates is that the image may not be
>> completely consistent in case of power failure or crash.  If the image is 
>> dirty
>> then it must be repaired before performing further modifications, in other
>> words we need an fsck-like scan on startup.
>>
>> I don't have performance results to share yet but I wanted to get the code 
>> out
>> there.  The bigger picture is that this optimization should help make qcow2 a
>> good choice even for cache=writethrough and cache=directsync where QED has
>> traditionally had an advantage due to less metadata - this allows us to
>> converge image format development in QEMU around the qcow2v3 format.
> Why do we design one new image format? e.g. use btree to manage
> metadata and disk data layout? Since btree has a lot of advantages
> than bitmap or tables.

The goal is not to reinvent btrfs, if we want that support for btrfs
file-level snapshots can be added to libvirt and QEMU will use raw
files on btrfs.  Although it's not clear yet what the performance of
disk images on btrfs is (I haven't seen at recent benchmark results
and it might not be that great).

Stefan