From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVz2K-0002Hf-39 for qemu-devel@nongnu.org; Tue, 15 Oct 2013 03:27:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VVz2E-0005z3-3p for qemu-devel@nongnu.org; Tue, 15 Oct 2013 03:27:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46909) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VVz2D-0005yF-Qi for qemu-devel@nongnu.org; Tue, 15 Oct 2013 03:27:18 -0400 Message-ID: <525CEE2D.10505@redhat.com> Date: Tue, 15 Oct 2013 09:26:37 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <52581B81.4080701@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH] drive-backup 'stream' mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wolfgang Richter Cc: Kevin Wolf , Fam Zheng , qemu-devel , imain , stefanha@redhat.com Il 14/10/2013 22:10, Wolfgang Richter ha scritto: > Okay, I think my impression might be wrong, but I thought > 'drive-mirror' would become deprecated with the new 'drive-backup' > command and code. > > If we look at what they do (current documentation and code), > 'drive-backup' AFAIK behaves the same for all modes of 'drive-mirror' > _except_ mode 'none' with _better_ consistency guarantees. That is, > 'drive-backup' clearly provides a point-in-time snapshot, whereas > 'drive-mirror' may create a point-in-time snapshot, but it can not > guarantee that. They are different. drive-backup provides a point-in-time snapshot at the time the job is started. Completing the job stops writing to the target. drive-mirror provides a copy at the time the job is completed. Completing the job stops writing to the source. > In addition, 'drive-backup's code is cleaner, simpler, and easier to > work with (in my opinion) than 'drive-mirror's code. This is because > of the new hooks in block.c for tracked requests etc. so that the job > can insert code to be run on every write in a clean manner (I think). The simpler code for drive-backup is because it doesn't have performance requirements. drive-mirror has to be optimized because otherwise too many dirty sectors pile up and the job doesn't converge. drive-backup runs synchronously as the VM writes to the disk. Using the hooks in block.c we can change drive-mirror to use an "active" (but still asynchronous) approach as long as the in-flight I/O does not exceed the size of the drive-mirror buffer. This would not simplify the code however, it would only guarantee that I/Os are performed in the same order as the original operations issued by the VM. Paolo