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