Mike,

AFS volume replication enables you to make one or many
ReadOnly replicas of a ReadWrite volume.

Since AFS has a built-in bias to access RO rather than RW
it does not make sense to try to replicate volatile data such as
user's $HOME volumes (see also [1]).

We use volume replication for the top level directories under /afs
(root.afs, root.cell, root.othercells and volumes mounted in root.cell)
and for static data such as executables, documentation (web pages),
and install images.

The benefit of replicating the top level directories in your cell is that
you still have access to your cell's filespace  in the event of a fileserver
outage.

One IBM internal cell I am working on, /afs/linux.ibm.com, is a multi-site
(2 USA and 2 UK) cell for the distribution of Linux distros.
We have a mirror copy of code from kernel.org in the which
is replicated between 3 locations. I use "rsync" to update the
"master" ReadWrite volume and then run "vos release kernel.org"
to synchronize the three ReadOnly replica volumes.
The kernel.org volume is 8GB and the benefit of using
"vos release kernel.org" is that only the incremental changes
are copied to the ReadOnly replicas _not_ the whole 8GB.

Use volume replication to improve the availability of your static data
and make your cell more robust.

Use a good AFS backup configuration to provide recovery
of data in ReadWrite volumes (eg mount backup volumes
so users can access "last-night's backup" on-line without
needing to ask for administrator's help).

I hope this helps.
--
cheers
paul                            http://acm.org/~mpb

References:
[1] AFS FAQ: "Can I replicate my user's home directory AFS volumes?"
     http://www.angelfire.com/hi/plutonic/afs-faq.html#sub3.16

Mike W Ellwood wrote:

> On 12 Aug 2000, Russ Allbery wrote:
>
> > AFS requires considerably less sysadmin overhead than a similar quantity
> > of data in NFS in my experience.  Location-independence and
> > user-transparent data moves means that we never have to schedule downtime
> > and can upgrade to new disk arrays without clients even *noticing*.  Try
> > doing that with NFS.
>
>
> I would not argue with the above.
>
> However, one benefit that we as a site were hoping to get from AFS
> seems not to be quite as good as we had thought: replication of
> volumes.
>
> Unless I am missing something, one can only replicate read-only copies
> of volumes.  That is quite a restriction.
>
> Or am I wrong?
>
> Just to give me a flavour of what I might possibly be missing,
> would anyone care to (briefly) summarise their own strategy regarding,
> or use of, AFS volume replication?
>
> I should add that we are lagging/lingering on 3.4a, which I fully realise
> is far from being the latest-and-greatest release.
>
> --
> [EMAIL PROTECTED]

Reply via email to