From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41957) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aUrdj-00050G-N4 for qemu-devel@nongnu.org; Sun, 14 Feb 2016 03:02:44 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aUrdi-0006f2-TN for qemu-devel@nongnu.org; Sun, 14 Feb 2016 03:02:43 -0500 Date: Sun, 14 Feb 2016 16:02:32 +0800 From: Fam Zheng Message-ID: <20160214080232.GE31933@ad.usersys.redhat.com> References: <56BA88E7.7010104@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56BA88E7.7010104@redhat.com> Subject: Re: [Qemu-devel] RFC: incremental backups: qmp-block-dirty-bitmap-diff List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: John Snow Cc: Qemu-block , qemu-devel , Vladimir Sementsov-Ogievskiy , Stefan Hajnoczi , "Denis V. Lunev" On Tue, 02/09 19:48, John Snow wrote: > - Reading an entire drive to populate a bitmap with the understanding > that an incremental backup is soon to follow is inefficient if the drive > is more than just a little dirty: it may have been quicker to just > create a new full backup and bitmap. Above all I think this is a good idea. Just as an alternative, can we add another sync mode for drive-backup? (QMP) drive-backup device=d0 target=target.qcow2 format=qcow2 sync=diff \ base=full-backup.qcow2 (the data of d0 will be compared against full-backup.qcow2 and only different clusters will be copied to target.qcow2) Fam