(Illustration by Gaich Muramatsu)
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 nowReceived on 2002-01-18 14:16:00