[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: Fri, 17 May 2013 14:58:57 +0800
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5

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

Backup applications need to support the full backup case anyway for
their first run.  Therefore we can keep a best-effort dirty bitmap which
is persisted only when the guest is terminated cleanly.  If the QEMU
process crashes then the on-disk dirty bitmap will be invalid and the
backup application needs to do a full backup next time.

The advantage of this approach is that we don't need to fdatasync(2)
before every guest write operation.

Compared with
current solution, I think it is doing COW at qemu device level:

     qemu device
general block layer
virtual format layer
|                     |
qcow2             vmdk....

   This will make things complicated when more works comes, a better
place for block COW, is under general block layer. Maybe later we
can adjust block for it.

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, and leaves an abstract API for
it. Some other operation such as commit, stream, could be also hide
under block.

qemu                 general testcase        other user
   |                       |                        |
        core block abstract layer(COW, zero R/W, image dup/backup)
          |                    |
    qemu's implement       3'rd party
          |                    |
    -------------        --------------
    |           |        |            |
  qcow2        vmdk     lvm2    Enterprise storage integration

  It is not directly related to this serial, but I feel some effort
should be paid when time allows, before things become complicated.

The drive-backup operation doesn't really affect the source
BlockDriverState, it just needs to intercept writes.  Therefore it seems
cleaner for the code to live separately (plus we reuse the code for the
block job loop which copies out data while the guest is running).
Otherwise we would squash all of the blockjob code into block.c and it
would be an even bigger mess than it is today :-).

Best Regards

Wenchao Xia

reply via email to

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