From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcrUn-0001qW-Kb for qemu-devel@nongnu.org; Thu, 16 May 2013 02:17:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UcrUi-0005Et-Lb for qemu-devel@nongnu.org; Thu, 16 May 2013 02:16:57 -0400 Received: from e28smtp03.in.ibm.com ([122.248.162.3]:58633) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcrUi-0005Eh-0b for qemu-devel@nongnu.org; Thu, 16 May 2013 02:16:52 -0400 Received: from /spool/local by e28smtp03.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 16 May 2013 11:41:55 +0530 Received: from d28relay03.in.ibm.com (d28relay03.in.ibm.com [9.184.220.60]) by d28dlp03.in.ibm.com (Postfix) with ESMTP id 8CFC01258023 for ; Thu, 16 May 2013 11:48:38 +0530 (IST) Received: from d28av05.in.ibm.com (d28av05.in.ibm.com [9.184.220.67]) by d28relay03.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r4G6Gbhe8520060 for ; Thu, 16 May 2013 11:46:37 +0530 Received: from d28av05.in.ibm.com (loopback [127.0.0.1]) by d28av05.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r4G6GgBI018180 for ; Thu, 16 May 2013 16:16:44 +1000 Message-ID: <519479B4.6080906@linux.vnet.ibm.com> Date: Thu, 16 May 2013 14:16:20 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <1368628476-19622-1-git-send-email-stefanha@redhat.com> In-Reply-To: <1368628476-19622-1-git-send-email-stefanha@redhat.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v3 0/8] block: drive-backup live backup command List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Fam Zheng , qemu-devel@nongnu.org, imain@redhat.com, Paolo Bonzini , dietmar@proxmox.com ÓÚ 2013-5-15 22:34, Stefan Hajnoczi дµÀ: > Note: These patches apply to my block-next tree. You can also grab the code > from git here: > git://github.com/stefanha/qemu.git block-backup-core > > This series adds a new QMP command, drive-backup, which takes a point-in-time > snapshot of a block device. The snapshot is copied out to a target block > device. A simple example is: > > drive-backup device=virtio0 format=qcow2 target=backup-20130401.qcow2 > > The original drive-backup blockjob was written by Dietmar Maurer > . He is currently busy but I feel the feature is worth > pushing into QEMU since there has been interest. This is my version of his > patch, plus the QMP command and qemu-iotests test case. > > QMP 'transaction' support is included since v3. It adds support for atomic > snapshots of multiple block devices. I also added an 'abort' transaction to > allow testing of the .abort()/.cleanup() code path. Thanks to Wenchao for > making qmp_transaction() extensible. > > How is this different from block-stream and drive-mirror? > --------------------------------------------------------- > Both block-stream and drive-mirror do not provide immediate point-in-time > snapshots. Instead they copy data into a new file and then switch to it. In > other words, the point at which the "snapshot" is taken cannot be controlled > directly. > > drive-backup intercepts guest writes and saves data into the target block > device before it is overwritten. The target block device can be a raw image > file, backing files are not used to implement this feature. > > How can drive-backup be used? > ----------------------------- > The simplest use-case is to copy a point-in-time snapshot to a local file. > > More advanced users may wish to make the target an NBD URL. The NBD server > listening on the other side can process the backup writes any way it wishes. I > previously posted an RFC series with a backup server that streamed Dietmar's > VMA backup archive format. > > What's next for drive-backup? > ----------------------------- > 1. Sync modes like drive-mirror (top, full, none). This makes it possible to > preserve the backing file chain. > > v3: > * Rename to drive-backup for consistency with drive-mirror [kwolf] > * Add QMP transaction support [kwolf] > * Introduce bdrv_add_before_write_cb() to hook writes > * Mention 'query-block-jobs' lists job of type 'backup' [eblake] > * Rename rwlock to flush_rwlock [kwolf] > * Fix space in block/backup.c comment [kwolf] > > v2: > * s/block_backup/block-backup/ in commit message [eblake] > * Avoid funny spacing in QMP docs [eblake] > * Document query-block-jobs and block-job-cancel usage [eblake] After checking the code, I found it possible to add delta data backup support also, If an additional dirty bitmap was added. 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. -- Best Regards Wenchao Xia