From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38512) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aFxg1-0001Hx-Qs for qemu-devel@nongnu.org; Mon, 04 Jan 2016 00:27:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aFxg0-00033v-Rm for qemu-devel@nongnu.org; Mon, 04 Jan 2016 00:27:29 -0500 References: <1449034311-4094-1-git-send-email-wency@cn.fujitsu.com> <56725496.1020408@cn.fujitsu.com> <20151223100407.GC11394@stefanha-x1.localdomain> From: Wen Congyang Message-ID: <568A02B2.9090208@cn.fujitsu.com> Date: Mon, 4 Jan 2016 13:27:14 +0800 MIME-Version: 1.0 In-Reply-To: <20151223100407.GC11394@stefanha-x1.localdomain> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Patch v12 resend 00/10] Block replication for continuous checkpoints List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Fam Zheng , zhanghailiang , qemu block , Jiang Yunhong , Dong Eddie , qemu devel , "Michael R. Hines" , "Dr. David Alan Gilbert" , Gonglei , Paolo Bonzini , Max Reitz On 12/23/2015 06:04 PM, Stefan Hajnoczi wrote: > On Thu, Dec 17, 2015 at 02:22:14PM +0800, Wen Congyang wrote: >> Stefan:Ping... >> >> What about this feature? I have worked for it about 1 year, but it is still in the >> way... > > The code still has TODOs. What is the plan for supporting replication > after failover? This feature seems critical because anyone who wants FT > won't be able to use this code unless it supports FT after the first > failure. We have implemented it based on an old version qemu. To keep the logical simple, we don't post them now. We will post them after this feature is merged into qemu. > > --- > > Adding new block layer APIs that are replication-specific is not clean. > Only the replication block driver cares about the start/stop/checkpoint > interface. > > It is cleaner to have a separate API and data structure for block > replication. > > The replication code should define its own BlockReplicationOps struct > and allow objects to register themselves. Then it's no longer necessary > to modify the core block layer to forward start/stop/checkpoint calls. > > Something like: > > typedef struct BlockReplicationOps BlockReplicationOps; > typedef struct BlockReplicationState { > const BlockReplicationOps *ops; > QLIST_ENTRY(BlockReplicationState) list; > } BlockReplicationState; > > typedef struct { > void start(BlockReplicationState *brs, Error **errp); > void stop(BlockReplicationState *brs, Error **errp); > void checkpoint(BlockReplicationState *brs, Error **errp); > } BlockReplicationOps; > > static QLIST_HEAD(BlockReplicationState) block_replication_states; > > void block_replication_add(BlockReplicationState *brs); > void block_replication_remove(BlockReplicationState *brs); > > The replication block driver would add/remove itself. The quorum block > driver probably doesn't need to be modified (I think in your current > patches you modify it just to forward the start/stop/checkpoint calls to > a particular quorum child). Yes, it is the major purpose. We also do some check in the quorum driver: we don't allow more than one child support block replication. Thanks Wen Congyang > > Stefan >