qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Wenchao Xia <xiawenc@linux.vnet.ibm.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Fam Zheng <famz@redhat.com>,
	qemu-devel@nongnu.org, imain@redhat.com,
	Paolo Bonzini <pbonzini@redhat.com>,
	dietmar@proxmox.com
Subject: Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command
Date: Fri, 17 May 2013 14:58:57 +0800	[thread overview]
Message-ID: <5195D531.3000402@linux.vnet.ibm.com> (raw)
In-Reply-To: <20130516074746.GF1597@stefanha-thinkpad.redhat.com>

于 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	other threads:[~2013-05-17  6:59 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-15 14:34 [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command Stefan Hajnoczi
2013-05-15 14:34 ` [Qemu-devel] [PATCH v3 1/8] block: add bdrv_add_before_write_cb() Stefan Hajnoczi
2013-05-15 14:42   ` Paolo Bonzini
2013-05-16  2:42     ` Wenchao Xia
2013-05-16  8:11     ` Stefan Hajnoczi
2013-05-15 14:34 ` [Qemu-devel] [PATCH v3 2/8] block: add basic backup support to block driver Stefan Hajnoczi
2013-05-16  3:27   ` Wenchao Xia
2013-05-16  7:30     ` Stefan Hajnoczi
2013-05-20 11:30   ` Paolo Bonzini
2013-05-21 13:34     ` Stefan Hajnoczi
2013-05-21 15:11       ` Paolo Bonzini
2013-05-21 15:25         ` Dietmar Maurer
2013-05-21 15:35           ` Paolo Bonzini
2013-05-21 15:54             ` Dietmar Maurer
2013-05-21 16:03               ` Paolo Bonzini
2013-05-21 16:15                 ` Dietmar Maurer
2013-05-21 16:26         ` Dietmar Maurer
2013-05-21 16:46           ` Paolo Bonzini
2013-05-22 13:37             ` Stefan Hajnoczi
2013-05-15 14:34 ` [Qemu-devel] [PATCH v3 3/8] block: add drive-backup QMP command Stefan Hajnoczi
2013-05-15 19:04   ` Eric Blake
2013-05-16  7:31     ` Stefan Hajnoczi
2013-05-15 14:34 ` [Qemu-devel] [PATCH v3 4/8] qemu-iotests: add 055 drive-backup test case Stefan Hajnoczi
2013-05-15 14:34 ` [Qemu-devel] [PATCH v3 5/8] blockdev: rename BlkTransactionStates to singular Stefan Hajnoczi
2013-05-15 19:09   ` Eric Blake
2013-05-16  2:28   ` Wenchao Xia
2013-05-15 14:34 ` [Qemu-devel] [PATCH v3 6/8] blockdev: add DriveBackup transaction Stefan Hajnoczi
2013-05-15 19:13   ` Eric Blake
2013-05-16  7:36     ` Stefan Hajnoczi
2013-05-15 14:34 ` [Qemu-devel] [PATCH v3 7/8] blockdev: add Abort transaction Stefan Hajnoczi
2013-05-15 19:01   ` Eric Blake
2013-05-16  2:26     ` Wenchao Xia
2013-05-16  7:37     ` Stefan Hajnoczi
2013-05-15 14:34 ` [Qemu-devel] [PATCH v3 8/8] qemu-iotests: test 'drive-backup' transaction in 055 Stefan Hajnoczi
2013-05-16  6:16 ` [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command Wenchao Xia
2013-05-16  7:47   ` Stefan Hajnoczi
2013-05-17  6:58     ` Wenchao Xia [this message]
2013-05-17  9:14       ` Stefan Hajnoczi
2013-05-21  3:25         ` Wenchao Xia
2013-05-21  7:34           ` Stefan Hajnoczi
2013-05-17 10:17     ` Paolo Bonzini
2013-05-20  6:24       ` Stefan Hajnoczi
2013-05-20  7:23         ` Paolo Bonzini
2013-05-21  7:31           ` Stefan Hajnoczi
2013-05-21  8:30             ` Paolo Bonzini
2013-05-21 10:34               ` Stefan Hajnoczi
2013-05-21 10:36                 ` Paolo Bonzini
2013-05-21 10:58                   ` Dietmar Maurer
2013-05-22 13:43                     ` Stefan Hajnoczi
2013-05-22 15:10                       ` Dietmar Maurer
2013-05-22 15:34                       ` Dietmar Maurer
2013-05-23  8:04                         ` Stefan Hajnoczi
2013-05-23  8:11                           ` Dietmar Maurer
2013-05-24  8:38                             ` Stefan Hajnoczi
2013-05-24  9:53                               ` Dietmar Maurer
  -- strict thread matches above, loose matches on Subject: below --
2013-09-02 12:57 Benoît Canet
2013-09-03  7:54 ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5195D531.3000402@linux.vnet.ibm.com \
    --to=xiawenc@linux.vnet.ibm.com \
    --cc=dietmar@proxmox.com \
    --cc=famz@redhat.com \
    --cc=imain@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).