Coda File System

Re: Coda development roadmap

From: <>
Date: Sat, 2 Aug 2014 00:59:32 +0200
On Fri, Aug 01, 2014 at 01:07:22PM -0500, Andrew Deason wrote:
> > - mountpoints are to contain a list of serverids (representing the VSG)
> >   and a volume id, iow no longer involving the Coda servers in the
> >   resolution of a mount point (this implies a possibility to create
> >   inconsistent mount points, which otoh doesn't look too dangerous)

> I'm a bit confused by this one. Would this mean you cannot move volumes
> to different servers? Since, if you changed what serverid(s) a volume
> was on, you'd need to go through every mountpoint referencing it to
> change the list of server ids.

In ("my") reality there is most often exactly one mountpoint per
(replicated) volume, so yes you would have to change that mountpoint -
being the incarnation of a corresponding "VRDB record".

(Moreover I always keep a mapping from a volume to its intended mount
point. Actually I perceive this as the most / only sane strategy of
structuring a realm.)

It means also that if you delete a mountpoint before the underlying
volume then you want to keep a record of its contents or instead collect
volume information from all servers, to keep track and be able to reuse
or remove the corresponding volume.

(Not a big difference from the current volume database management

I think of mountpoints as references to internal data and hence
their creation being preferably a privileged/administrative operation.
Thus, coordinated creation / bookkeeping of mountpoints in a realm is fully
possible. Using multiple mountpoints referring to the same volume
may have other harmful effects, iow hardly advisable. Lack of such
cases makes bookkeeping easy.

> (I have very little familiarity with Coda and I'm not spending a
> terribly large amount of time reading this, so sorry if this was
> addressed elsewhere or is otherwise a dumb question :)

Not at all, thanks for asking.

The logic has to be questioned and verified.
Otherwise it can be discovered to be broken, several man-years later.

Received on 2014-08-01 19:00:14