[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Patch v12 resend 00/10] Block replication for continuo

From: Stefan Hajnoczi
Subject: Re: [Qemu-block] [Patch v12 resend 00/10] Block replication for continuous checkpoints
Date: Wed, 23 Dec 2015 18:04:07 +0800
User-agent: Mutt/1.5.24 (2015-08-30)

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


Adding new block layer APIs that are replication-specific is not clean.
Only the replication block driver cares about the start/stop/checkpoint

It is cleaner to have a separate API and data structure for block

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).


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]