On 04/23/2015 06:44 PM, Paolo Bonzini wrote: > > > On 23/04/2015 12:40, Kevin Wolf wrote: >> The question that is still open for me is whether it would be a colo.c >> or an active-mirror.c, i.e. if this would be tied specifically to COLO >> or if it could be kept generic enough that it could be used for other >> use cases as well. > > Understood (now). > >>>> What I think is really needed here is essentially an active mirror >>>> filter. >>> >>> Yes, an active synchronous mirror. It can be either a filter or a >>> device. Has anyone ever come up with a design for filters? Colo >>> doesn't need much more complexity than a "toy" blkverify filter. >> >> I think what we're doing now for quorum/blkverify/blkdebug is okay. >> >> The tricky and yet unsolved part is how to add/remove filter BDSes at >> runtime (dynamic reconfiguration), but IIUC that isn't needed here. > > Yes, it is. The "defer connection to NBD when replication is started" > is effectively "add the COLO filter" (with the NBD connection as a > children) when replication is started. > > Similarly "close the NBD device when replication is stopped" is > effectively "remove the COLO filter" (which brings the NBD connection > down with it).
Hmm, I don't understand it clearly. Do you mean: 1. COLO filter is quorum's child 2. We can add/remove quorum's child at run-time. If I misunderstand something, please correct me. Thanks Wen Congyang > > Paolo > . >