From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46943) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcIMR-0004bY-2y for qemu-devel@nongnu.org; Tue, 14 May 2013 12:46:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UcIMM-0004rE-KU for qemu-devel@nongnu.org; Tue, 14 May 2013 12:45:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45408) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcIMM-0004r2-8C for qemu-devel@nongnu.org; Tue, 14 May 2013 12:45:54 -0400 Message-ID: <51926A37.3060902@redhat.com> Date: Tue, 14 May 2013 18:45:43 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20130514085046.GA2556@dhcp-200-207.str.redhat.com> <51920C30.4050407@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] block-trace Low Level Command Supporting Disk Introspection List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wolfgang Richter Cc: Kevin Wolf , qemu-devel , stefanha Il 14/05/2013 17:48, Wolfgang Richter ha scritto: > On Tue, May 14, 2013 at 6:04 AM, Paolo Bonzini > wrote: > > Il 14/05/2013 10:50, Kevin Wolf ha scritto: > > Or, to translate it into our existing terminology, drive-mirror > > implements a passive mirror, you're proposing an active one (which we > > do want to have). > > > > With an active mirror, we'll want to have another choice: The > mirror can > > be synchronous (guest writes only complete after the mirrored > write has > > completed) or asynchronous (completion is based only on the original > > image). It should be easy enough to support both once an active mirror > > exists. > > Right, I'm waiting for Stefan's block-backup to give me the "right" > hooks for the active mirror. > > The bulk phase will always be passive, but an active-asynchronous mirror > has some interesting properties and it makes sense to implement it. > > > Do you mean you'd model the 'active' mode after 'block-backup,' or actually > call functions provided by 'block-backup'? No, I'll just reuse the same hooks within block/mirror.c (almost... it looks like I need after_write too, not just before_write :( that's a pity). Basically: 1) before the write, if there is space in the job's buffers, allocate a MirrorOp and a data buffer for the write. Also record whether the block was dirty before; 2) after the write, do nothing if there was no room to allocate the data buffer. Else clear the block from the dirty bitmap. If the block was dirty, read the whole cluster from the source as in passive mirroring. If it wasn't, copy the data from guest memory to the preallocated buffer and write it to the destination; > If I knew more about what you > had in mind, I wouldn't mind trying to add this 'active' mode to > 'drive-mirror' > and test it with my use case. I want to avoid duplicate work, so if you > want to implement it yourself I can defer this. Also the other way round. If you want to give it a shot based on the above spec just tell me. It should require no changes to block.c except for adding after_write. Paolo