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.
---
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).
Stefan
signature.asc
Description: PGP signature
