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.

Jan