(Illustration by Gaich Muramatsu)
On Sun, Oct 06, 2002 at 01:32:59PM +0200, Ivan Popov wrote: > Right now it is not supported (?) to modify a volume storage group or to > move volumes between the groups. > Volume groups historically have had strong connection to IP muticast > groups, while multicasting is not used nowadays, I think. As far as the client in concerned it doesn't really matter when a volume's replication changes, the only thing the server has to do it to disconnect the RPC connections to force clients to recheck the volume mapping and revalidate all cached objects against the new "server group". However the VSG is still used in many places in the server because the volume replication and location code is still intricately tied into COP2 handling (phase2 RPC of the 2 phase commit), server-server resolution and probably various other places. > I'd rather see a (<name>,<server>) volume identifiers, with > create/remove operations applicable [just?] to such pairs. It would Ideally I'd like to see that as well. This would allow us to do 'createvol_rep <volumename> [<serverN>[:port][/partition]]+', i.e. createvol_rep testvol verdi/vicepa mozart:9999/foo marais which would create replicas on the codasrv on verdi in partition /vicepa, on a server running on mozart (at port 9999) in partition foo, and on marais on the default partition. Perhaps at some point someone could even run, purgevol_rep testvol verdi # remove one of the testvol replicas from verdi createvol_rep testvol vivaldi # add a replica to vivaldi But that's just dreaming right now... Oh, and because we have client triggered resolution removing a replica might lead to dataloss. So moving a volume by creating a new replica, forgetting to make sure it is 100% reliably and totally resolved before removing the old wouldn't be the smartest choice, although everyone would probably try it at least once. > Would it be a major rewrite to do it so? > Is the volume storage groups database really necessary, even internally? Internally it is definitely necessary, a server needs to know whether an update made it to all replicas given the COP2 message. It cannot trust the client to say 'sure I updated everyone', so it needs to locate all other replicas in the VSG. Same thing for server-server resolution. JanReceived on 2002-10-06 15:42:23