Jamey, you should always replicate volumes on the readwrite location
as well as on all the other locations. The reason for this is that
when a readonly volume exists if it is unreachable the cache manager
will never fall back to the readwrite copy due to consistency
considerations. So if in your example you only make a readonly copy
on server B, if server B goes down the volume will become unavailable.
You are also better off making the extra copy on the readwrite location
as opposed to on a different server/partition because then AFS can
use a copy-on-write technique which saves you a lot of disk space.
(We have figured out that the overhead for readonly volumes created
on the readwrite site is usually less than 10%).
As far as what the user sees when a server that it's trying to access to
get a readonly volume fails the following is usual scenario: a long delay,
a 'Lost contact with fileserver xxxx' message on the console and then the
file gets fetched from the another server. This is assuming that the first
fileserver contacted didn't respond at all. If the fileserver is up but the
volume is inaccessible (deleted or off-line) you'll get a 'No such device'
error. This last case is clearly not the best behavior and I heard that it
has been fixed in 3.2 (i.e. it will try another server even if the first
server responds that the volume is not accessible)
