Coda File System

Re: volume and replicas naming

From: Jan Harkes <>
Date: Sun, 5 Nov 2006 11:46:21 -0500
On Sun, Nov 05, 2006 at 03:24:38PM +0100, wrote:
> The small limitation noted above renders such consequent naming
> impossible, as soon as you have directories
>  something and something.digit
> and need them to be mount points for different volumes.
> I would suggest using a prefix instead of a suffix for replica names,
> so that a mount point /coda/realm/foo could correspond to volume "/foo"
> but the replicas would be instead "0/foo", "1/foo" and so on,
> never being able to erroneously match a path.

Volumes actually have several names. They are also reachable through the
decimal representation of their volume id. Except for making recognition
simpler there is no technical reason why replicas have the .N suffix. It
makes it easier to use sort and get all related replicas listed, but
their names technically don't have to match their replica at all. When
we expand an object to show the underlying replicas we use the
volume-id's, not the names.

However there are a couple of places where we implicitly add .suffix,
for instance for clones and backup volumes.

> I wonder how deeply the current naming convention is hardwired into Coda,
> would it be sufficient to modify createvol_rep / purgevol_rep scripts
> to introduce the change? (then I could do it for my realms myself).

I'm not 100% sure but I think those are the only places where we add the
suffixes. I'm 99% sure that the replicas could be given the identical
name as their replicated parent because the lookup should check the
replicated volume database before we even look at the list of replicas.

Once the name is mapped to a (replicated) volume id, any further lookups
are not based on the names, but on the replicas. I only use the replica
names to mount the backup volume under either 'OldFiles' or at
/coda/.../backups/  This is because it is possible for backup volumes
to get a different volume-id (if previous backup failed), but the names
will currently always be 'replicatedname.N.backup' and if the replicas
had the same name as the replicated volume it would be the non-unique

Now if the client had a way to get the list of clone and backup volumes
they could be shown when we expand an object alongside the replicas,
something like,

    $ cfs expand foo
    $ ls -l foo
    -rw-r--r-- 1 7768 nogroup 41 2005-08-02 12:02
    -rw-r--r-- 1 7768 nogroup 41 2005-08-02 12:02
    -rw-r--r-- 1 7768 nogroup 41 2005-08-02 12:02
    -rw-r--r-- 1 7768 nogroup 41 2005-08-02 12:02
    -rw-r--r-- 1 7768 nogroup 41 2005-08-02 12:02
    -rw-r--r-- 1 7768 nogroup 41 2005-08-02 12:02

Or possibly append the date+time when the backup or clone volume was
created (@20061105001511). This way we never need to rely on the name in
the volume database to access backup volumes because expand mounts them
based on the volume-id, it just needs a way to discover what those id's are.

Received on 2006-11-05 11:48:18