From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46261) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzUIJ-0003OF-1S for qemu-devel@nongnu.org; Mon, 20 Feb 2012 09:32:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzUIH-0002Tm-P6 for qemu-devel@nongnu.org; Mon, 20 Feb 2012 09:32:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:30069) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzUIH-0002Ti-IZ for qemu-devel@nongnu.org; Mon, 20 Feb 2012 09:32:45 -0500 Message-ID: <4F425987.20103@redhat.com> Date: Mon, 20 Feb 2012 15:32:39 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <73865e0ce364c40e0eb65ec6b22b819d@mail.gmail.com> <4F31153E.9010205@codemonkey.ws> <4F311839.9030709@redhat.com> <4F311BBA.8000708@codemonkey.ws> <4F312FD3.5020206@zerto.com> <4F3137DB.1040503@redhat.com> <4F3139CE.4040103@zerto.com> <4F314798.8010009@redhat.com> <4F3211D0.3070502@zerto.com> <4F323875.1000000@redhat.com> <4F3244C2.1040604@zerto.com> <4F32489A.80307@redhat.com> <4F32788C.60904@zerto.com> <4F40FBD6.2000500@zerto.com> In-Reply-To: <4F40FBD6.2000500@zerto.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] Replication agent design (was [RFC PATCH] replication agent module) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ori Mamluk Cc: Kevin Wolf , =?UTF-8?B?16rXldee16gg15HXnyDXkNeV16g=?= , Stefan Hajnoczi , dlaor@redhat.com, qemu-devel@nongnu.org, =?UTF-8?B?16LXldeT15Mg16fXk9ed?= , Yair Kuszpet On 02/19/2012 02:40 PM, Ori Mamluk wrote: > > I think it might be better to go back to my original less generic design. > We can regard it as a 'plugin' for a specific application - in this > case, replication. > I can add a plugin interface in the generic block layer that allows > building a proper storage stack. > The plugin will have capabilities like a filter driver - getting hold of > the request on its way down (from VM to storage) and on its way up (IO > completion), allowing to block or stall both. I and Stefan talked about this recently... we called it a BlockListener. It seems like a good idea, and probably copy-on-read should be converted in due to time to a BlockListener, too. Paolo