Hello Jan,

thanks for the analysis!

Glad it looked reasonable for you too.

On Tue, 20 Aug 2002, Jan Harkes wrote:

> I see a point for larger volume names, although that breaks the existing
> client-server rpc's. I think the '/' character can be used already.

Wonder if the constants are "hardcoded" in the protocol (like 1-byte for
the length) or it may be a matter of changing defines and recompiling both
client and server?

> It would mix in well with the stuff I'm working on

It sounds great.

> "@realm", while regular volumes are "foo.bar_at_realm". I'm currently only
> allowing cross-realm mounts from a special dynamic directory, which has
> these kinds of links,
>     /coda/testserver.coda.cs.cmu.edu -> @testserver.coda.cs.cmu.edu
>     /coda/coda.cs.cmu.edu -> @coda.cs.cmu.edu

Nice!

> I do have some questions. How do you propose to address backup volumes,
> underlying volume replicas (i.e. during repair), and cloned volumes. I
> think we still need to keep the old methods of mounting a volume around
> for at least these.

Well, such special mounts have to be treated specially and one solution is
to use the "old" method of mounting then. Though I'd prefer another
approach - getting rid of arbitrary mounts at all:

/coda/realm.somewhere/dir/mntpoint              regular files

/coda/.replicas/realm.somewhere/dir/mntpoint/0  replicas
/coda/.replicas/realm.somewhere/dir/mntpoint/1
 ...
/coda/.backup/realm.somewhere/dir/mntpoint      backup
 ...

To preserve filesystem semantics, the
  <magicprefix>/realm/dir/mntpoint
lookup should use the same
  realm/dir/mntpoint
path as the regular lookup, but just change the semantics of the mntpoint.

[similar solution exists in dfs for accessing read-write replicas]

Note that no conflicts with realm names should happen as long as they do
not begin with a dot. Purists probably would like

/coda/regular/realm.../.....
/coda/replicas/realm....
  and so on

Best regards,
--
Ivan