Hello Joe,

> All with success.  Now, I understand that I can create volumes inside these
> (like a nested directory).  But how is this done.   What does the volume ID
> (E0000104, E0000100) really mean.

unfortunately the documentation is far from being really pedagogical :)

Let me try to make some statements that may help:

 - all of volumes logically are exactly "equal" on themselves
   (there is no hierarchy between volumes,
   it is introduced by their mountpoints, which map volumes' contents
   into the file tree)
 - each volume is represented by one to several replicas
   (there is a volume - containing "in some way" some data, and there are
   its instances, replicas, located at different servers but all
   containing that the same data...)

 - to describe replicas placement across servers, there is a concept,
   (being phased out!) called "volume storage groups", so that a volume
   just belongs to a "group" containing several servers, and this means
   that those servers have replicas of the volume.
   The concept has its roots in the IP v4 multicast groups that were
   apparently used to make data replication between servers more efficient
   but multicasting is not used in Coda any more.
 - the volume storage groups are denoted by ids like E0000100
   (which is a multicast address 224.0.1.0)

 - there is a filesystem tree, beginning at /coda[/realm.name], containing
   files and directories, file operations like mkdir() work as supposed

 - at any node in the tree there can be an object called "mountpoint"
   that means that the objects immediately under this point are located
   on a certain volume
   i.e. a mountpoint maps its name (point in the tree like
   "/coda/some/thing") to a volume name (from a flat namespace, like
   "volume123"
 - mountpoints have to be created/deleted in a special way, by "cfs"
   utility

 - one of the volumes is used to contain the beginning of the tree
   belonging to a certain realm (contents of /coda in the old times,
   and a contents of /coda/realm.name nowadays, Coda version <=5 and >= 6
   respectively)

 - instead of arranging a mountpoint at the very beginning of the tree,
   which is a complicated thing, there is an extra hook in the server
   and client code, so that a server has to know which volume contains
   the root directory, and tells about that to the clients when they
   begin to read the Coda tree
 - that server idea of rootvolume _can_ be overridden on a client
   by an option in venus.conf, then that client gets a very different view
   of Coda tree - it is useful in rare cases, for troubleshooting

Cheers,
--
Ivan