Am 23.04.2015 um 12:33 hat Paolo Bonzini geschrieben: > On 23/04/2015 12:17, Kevin Wolf wrote: > > > Perhaps quorum is not a great match after all, and it's better to add a > > > new "colo" driver similar to quorum but simpler and only using the read > > > policy that you need for colo. The new driver would also know how to > > > use BDRV_O_NO_CONNECT. In any case the amount of work needed would not > > > be too big. > > > > I thought the same, but haven't looked at the details yet. But if I > > understand correctly, the plan is to take quorum and add options to turn > > off the functionality of using a quorum - that's a bit odd. > > Yes, indeed. Quorum was okay for experimenting, now it's better to "cp > quorum.c colo.c" and clean up the code instead of adding options to > quorum. There's not going to be more duplication between quorum.c and > colo.c than, say, between colo.c and blkverify.c.
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. > > 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. Kevin
