On Tue, Oct 10, 2000 at 12:03:20PM +0000, Stephen Torri wrote:
> On Mon, 9 Oct 2000, Jan Harkes wrote:
> > 
> > I'm not sure what you mean with the question, I guess `df' would show:
> > 
> > Filesystem         1024-blocks  Used Available Capacity Mounted on
> > /dev/hdb8		xxxx	xxxx	xxxx	x%	/vicepa
> > 
> > Jan
> > 
> 
> I can see the partition on the main server as /vicepa. I can see its
> details when I do "df".
> 
> Now I put my install log file (install.log) there in /vicepa as a target
> for my test. I then logged in as administrator (will add users soon) via
> clog. I then tried to view the /coda directory. I could not see the
> contents of /vicepa. I am sure this is something simple that I missed. Can
> you point me to the chapter of the manual?

Hi Stephen,

I hope you don't mind me CC'ing this message to codalist, because I've
received this question often, so I guess the answer deserves a larger
audience.

Coda doesn't work like NFS, if you create a file somewhere /coda on the
client the data is stored in a logical volume on the servers that serve
the data for this volume. The metadata is kept in RVM, the contents of
the file are stored in a file in /vicepa.

I'll try to explain by example,

    echo 1234 > /coda/usr/jaharkes/testfile

Here at CMU, /coda/usr/jaharkes is the volume vmm:u.jaharkes, a triply
replicated volume stored on the servers verdi, mozart, and marais.

These server actually handle many volumes (about 100 I believe). And
they all allocate a unique cache file for the data,

verdi happens to pick /vicepa/00/00/01/FF, mozart uses /vicepa/00/01/00/FE,
etc. They also store in RVM data the information that the root directory
of vmm:u.jaharkes now has a new entry named testfile, and the file's
metadata such as size, mode, owner, creator, timestamps, a versionvector
and which `containerfile' in /vicepa holds the data for this file.

Some of this metadata could have been stored as attributes on the
container-file, but we don't do this for several reasons. For instance,
I don't have an user account on the servers, so the owner would already
become difficult. Forcing timestamps is messy, and setting the mode
would potentially make files on the server visible to people who
shouldn't have access to them. Also, there is no alternative for the
VersionVector, which is probably the most critical information we have
about a file as it is used to check consistency between copies of the
file in different locations, server-server replication (resolution), and
client-cache validity (f.i. after a disconnection).

So /vicepa/install.log might exist, but as the server doesn't know about
all the _important_ stuff, it is completely useless to the server and it
simply ignores the fact that it is there. Besides, we really don't want
to have the server scan a N-gig /vicepa tree to figure out whether
someone happened to have added a file there locally.

To summarize, you can only put files in Coda through a client, and they
can only be (correctly) read back using a Coda client.

Jan