On Fri, Jan 18, 2002 at 03:43:46PM +0100, Ivan Popov wrote:
> I mean:
> 
>  - a backup volume - if it can be turned to a read-write one?
>    (desirable while reading backups as a disaster recovery,
>     last time it was mentioned on the list the answer was "no but may be
>     later yes")

I still haven't had time to look at what exacly is different between a
restored backup volume and it's original rw-replica. If they are
identical, it's just a matter of 'flipping a bit' in the volume header.
If there are differences we'll need to have some kind of conversion
step, but I'm assuming this would probably be very minor as all types of
volumes and vnodes are using identical data structures on the server.

>  - is it possible to move a volume to another storage group?
>    (rearranging servers, moving data between servers)

When looking for the replication bug, I made a shocking discovery. The
volume entries in the VRList are reordered when creating the VRDB
according to the ip-addresses of the servers that host the replicas.

This is evil, because many things depends on the volume ordering in the
VRDB, i.e. which range of fids a server is allowed to allocate, which
slot in the version-vector corresponds to the current server, etc. And
any (small) change, like giving a server a new ip-address, or adding a
volume/removing a volume can perturb the ordering. This will cause
severe problems like old or missing data to be identified as the latest
version during resolution, servers passing conflicting fids to
about to disconnect and reconnecting clients, etc.

The behaviour can be fixed by removing the reordering (i.e. the call to
vre->Canonicalize()) when we're creating the VRDB, but... this will
break any installations whose VRList entries are currently being
reordered, so migration to the 'safe state' will be tricky. One solution
would be to have a 'volutil dumpvrdb' which would recreate a VRList file
from the internal VRDB state which would have to be run before creating
any volumes on the new servers. After that everything should work fine,
although we might see some breakage in places that were relying on the
fact that the volumes in the VRDB are sorted according to server address.

>  - is it possible to change the member list in a storage group?
>    modify, add, delete?
>    (the same - moving data between servers)

The client is pretty much ready to deal with this. We just need to hook
a forced volume revalidation as a result of f.i. a volume callback.

> Ivan
> in the process of rearranging servers :)

Jan
wondering how many things are going to break now