On Fri, 18 Jan 2002, Jan Harkes wrote:

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

It would be great to have as a recovery solution. (See my note at the end
below).

> volume entries in the VRList are reordered when creating the VRDB

> 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

Why that reordering came to existence then? There should have been some
rationale behind that?

> >  - is it possible to change the member list in a storage group?
> >    modify, add, delete?

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

Does it mean that it would work with current software - if I for instance

1. for each volume in a storage group
   create empty volume replicas on a new server (how would I do that?)
2. add the new server to an existing storage group by editing VSGDB like
   that:
   E000100 srv1 srv2 newserv
3. restart all servers
4. reinit all clients
5. ls -alR /coda

Would it work as long?

6. remove an old server from VSGDB like that:
   E000100 srv2 newserv
7. restart all servers
8. reinit all clients
9. remove volumes replicas on srv1

Would it work as well?

> > in the process of rearranging servers :)
>
> Jan
> wondering how many things are going to break now

Sorry, I can't afford broken things :) If there is no better way,
I'll hack a script collecting acls from a volume and storing along with
the data archive, then restoring both data and acls.
Surprised there is no such utility yet. (see my note at the beginning :)

So long I am just expanding the system, but I will have to move data
around for being able to make safe server upgrades, both hard- and
software. How do you solve it??

See you,
--
Ivan