On Thu, Feb 15, 2001 at 10:00:32AM -0500, Ha Duong Minh wrote:
> > I don't see why this is a problem.  It's not that many links;
> > I don't see any way to avoid links with current Coda technology, since
> > there can only be one /coda per machine.  So you couldn't mount coda
> > on both /home and /usr/share (and AFAIK mounting somewhere other than
> > /coda is not all that well tested).
> 
> I agree this may not be many links, but let me explain two problems:
> 
> 1/ No documentation of how to integrate Coda in an infrastructure.
> In my case, and I suspect it's representative, I am discussing wether we
> shall use Coda in our research lab with a fellow PhD student that is highly
> computer litterate, but does not has an experience in network
> administration. We can't find real-world examples showing how it is
> actually used in practice. And we don't feel like reinventing the wheel.

That's perhaps because not many people have integrated Coda in an
existing infrastructure, or they looked at how AFS gets integrated.

Every infrastructure has it's own tweaks, there is no one way of
deploying something. Common combinations are AFS/kerberos or NFS/NIS+,
but there are always other choices such as LDAP, or X500, or simply rely
on local-only /etc/passwd files.

> 2/ Psychology:
> Giving away a large chunk of hard disk space is not something I do
> everyday. Mounting anything new under / is something I have _never_ done.
> Moreover, I can't see any rational reason why coda does not mounts by
> default as  /mnt/coda. You know people tend to fear what they do not
> understand.

What large chunk of diskspace? As far as the rationale for /coda is
concerned, AFS, from which Coda stems has always used /afs. Also, many
people use /mnt as a point to temporarily mount devices, and not
subdirectories in /mnt. Now if we had /mnt/coda, surprise, the Coda tree
disappears as soon as an unexpecting user mounts his CD.

More reasons? When the mountpoint is arbitrary, someone might assume
that Coda is like NFS, and tries to create Coda mountpoints everywhere.
Now, /coda provides a common centralized access path to a large
distributed filespace. It is always the same, whether your client is
running Solaris, NetBSD, FreeBSD, Linux, etc.

Also, several client applications need an authenticated path to the
cache manager (clog, ctokens, cfs), which happends to go through a
control file in the mounted Coda FS. How are they going to known/find
which mounted fs to use, and where it is mounted.

And then we have the subtle advertising, when someone does 'ls /', they
see that the system has something interesting named "coda". That is
ofcourse the real reason we're not using "/abracadabra" as the name of
our mountpoint. 

> Now adding 1+2 together, my friend's judgment was "it totally breaks the
> file system" and I could not have a valid answer.

I can only smile at that. What is he referring to as `the file system'?

File system semantics? Such as UNIX, or AFS semantics, where Coda tries
to adhere mostly to the AFS semantical model?

I guess he is referring to the Filesystem Hierarchy Standard, which is a
mere suggestion for a local policy on how to find files on a machine,
and it says nowhere in the FHS that symlinks like /usr -> /coda/usr are
not allowed. As long as the user can type /usr/bin/{vi,emacs}, he is
happy.

Your email address is from CMU, so I guess you must be familiar with
AFS, and perhaps even with "depot" which facilities uses to manage the
installation/maintenance of thousands of machines on campus. Does your
friend consider that as "totally breaking the file system" as well?

Jan