[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command

From: Wenchao Xia
Subject: Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command
Date: Tue, 21 May 2013 11:25:01 +0800
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6

于 2013-5-17 17:14, Stefan Hajnoczi 写道:
On Fri, May 17, 2013 at 02:58:57PM +0800, Wenchao Xia wrote:
于 2013-5-16 15:47, Stefan Hajnoczi 写道:
On Thu, May 16, 2013 at 02:16:20PM +0800, Wenchao Xia wrote:
   After checking the code, I found it possible to add delta data backup
support also, If an additional dirty bitmap was added.

I've been thinking about this.  Incremental backups need to know which
blocks have changed, but keeping a persistent dirty bitmap is expensive
and unnecessary.

   Yes, it would be likely another block layer, so hope not do that.

Not at all, persistent dirty bitmaps need to be part of the block layer
since they need to support any image type - qcow2, Gluster, raw LVM,

I don't consider block jobs to be "qemu device" layer.  It sounds like
you think the code should be in bdrv_co_do_writev()?

   I feel a trend of becoming fragility from different solutions,
and COW is a key feature that block layer provide, so I wonder if it
can be adjusted under block layer later

The generic block layer includes more than just block.c.  It also
includes block jobs and the qcow2 metadata cache that Dong Xu has
extracted recently, for example.  Therefore you need to be more specific
about "what" and "why".

This copy-on-write backup approach is available as a block job which
runs on top of any BlockDriverState.  What concrete change are you

  Since hard to hide it BlockDriverState now, suggest add some
document in qemu about the three snapshot types: qcow2 internal,
backing chain, drive-backup, which are all qemu software based snapshot
implemention, then user can know the difference with it eaiser.

  In long term, I hope to form a library expose those in a unified
format, perhaps it calls qmp_transaction internally, and make it
easier to be offloaded if possible, so hope a abstract-driver structure.
Best Regards

Wenchao Xia

reply via email to

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