Coda File System

Re: multilevel backups (and an introduction to moving volumes)

From: <>
Date: Tue, 17 Feb 1998 10:23:14 -0500
"Peter J. Braam" <> ,in message <Pine.LNX.3.95.980217001835.724>, wrote: 

> Moving volumes works as follows: lock the volume - make a copy on write
> clone. Unlock the volume (i.e. it can be used again).  Dump and move the
> clone to a new server. Note that the volume can be large, so this can take
> a while - but the volume is available again. Now lock the volume again,
> and make an incremental dump; keep the volume locked. Move the
> incremental, and merge.  Note that this is supposed to be quick, since
> even for a large volume probably not much changes. Bring the new volume
> online and disable the old volume.

  Here's an idea that I'm sure one or two people have already had.  Since I
haven't had much time to play, the feasibility of assorted parts is
questionable.  If it won't work, we could all learn a lot from the explanation
why not.

  What if you could declare one host a "replicant wannabe"?  He wants to be a
replicant of one volume, but doesn't have the data on the disk.  If you're on a
fast network, the machine just starts downloading files from the other servers.
If a client asks him for a file he doesn't have, he grabs it from one of the
other servers immediately and then serves it up.  Eventually (you hope) he does
sync up with the other servers and comes truly on-line.

  If you're not on a fast network, that could take a while.  So, instead you
lock the volume, make a copy-on-write clone, and inform the original server set
that this new server is consistent with the locked volume, but is partitioned
from the network.  You unlock the volume, make your dump of the COW clone
(uhoh, now we're cloning COWs), and restore it on the new machine.  At this
point, you have made good on your promise to the rest of the server set.  You
then "un-partition" it from the network.  Would coda have enough umph to sync
the new machine using the changes while it was "partitioned"?

Bob Forsman                         
Received on 1998-02-17 10:27:22