Coda File System

design, go beyond AFS?

From: Ivan Popov <>
Date: Mon, 19 Aug 2002 15:11:44 +0200 (MET DST)

I have thought about experiences of AFS and DFS deployment at our
university since 1997, where I have been rather heavily involved,
and my own experiences with Coda.

I have not seen anything that would really need the separation between
mount point name space and volume name space.

Rather opposite is true, the arbitrary mapping between volumes and mount
points creates confusion and even semantical inconsistency (in manuals
for afs, dfs, coda you read "do not create multiple mount points for the
same volume", that means we have not fully implemented the semantics and
it works essentially by chance - there is nothing that can prevent
creation of multiple mount points, in the general case).

No functionality would be lost and a lot of problems avoided if
hypothetical volume names would have to coincide with the mount point
names. I mean - always. (given of course that there is a "rename"
operation on volumes).

Then maintainance of the system becomes a lot easier as you always know
where a volume belongs. Otherwise the administrator *has* to maintain the
mapping, and it must be simple to be manageable - but then it becomes a
limitation - you cannot make complicated trees of mountpoints even when it
is perfectly adequate for the particular application.

Our dfs deployment project at the university had to develop special
path-fileset mapping tools for that reason and still it is a burden to
manage filesets.

I know that Coda has inherited its internal structures from AFS but
we have a chance to make changes. It would make the system more logical
(hence more robust), more manageable and more appealing, just by getting
rid of the arbitrary mountpoint-volume mapping.

[Note that AFS has made a step from the traditional Unix "arbitrary
mounts", /afs is always /afs not /we/mount/afs/here and it the Right
thing. Now we have many more years of experience and have the
possibility to make another step in similar direction.]

To conclude, I'd welcome volume names that allowed any characters
including '/', with length up to MAXPATHLEN (I mean "big enough", like
4 Kbyte, that would not cost a lot of space, typical volumes are much
larger than 4K :-)
(The volume name would not have to include the standard "/coda/" prefix,
of course)

Then mountpoints would not have to contain any information except "I'm a
Some arguments to some commands would disappear, and mount point path
and volume name could be used interchangeably. Hope you see the point.

Note that I do not advocate a redesing - the concepts are proven and good.
I advocate removing a hardly used feature that is
 - unnecessary, [a bit] dangerous, confusing and burdensome

Best regards and thanks for the great software!
Received on 2002-08-19 09:17:02