From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52992) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcX1L-0006zx-JM for qemu-devel@nongnu.org; Wed, 15 May 2013 04:25:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UcX1K-00064X-CZ for qemu-devel@nongnu.org; Wed, 15 May 2013 04:25:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5173) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UcX1K-00064D-35 for qemu-devel@nongnu.org; Wed, 15 May 2013 04:25:10 -0400 Message-ID: <5193465C.1040006@redhat.com> Date: Wed, 15 May 2013 10:25:00 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <20130514085046.GA2556@dhcp-200-207.str.redhat.com> <51920C30.4050407@redhat.com> <51926A37.3060902@redhat.com> <20130515075904.GA2858@dhcp-200-207.str.redhat.com> In-Reply-To: <20130515075904.GA2858@dhcp-200-207.str.redhat.com> 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: Kevin Wolf Cc: Wolfgang Richter , qemu-devel , stefanha Il 15/05/2013 09:59, Kevin Wolf ha scritto: >>> 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). > > Makes me wonder if using a real BlockDriver for the filter from the > beginning wouldn't be better than accumulating more and more hooks and > having to find ways to pass data from 'before' to 'after' hooks... We don't need a way to pass data from before to after hooks, a simple scan of a linked list will do. >> 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; > > Does the "if there was no room" part mean that the mirror is active only > sometimes? Yes, otherwise the guest can allocate arbitrary amounts of memory in the host just by starting a few very large I/O operations. > And why even bother with a dirty bitmap for an active mirror? The > background job that sequentially processes the whole image only needs a > counter, no bitmap. That's not enough for the case when the host crashes and you have to restart the mirroring or complete it offline. Paolo > At which point it looks like implementing it separate from mirror.c > could make more sense. > > Kevin >