Coda File System

Re: Replicated volume upgrades

From: Ivan Popov <>
Date: Sat, 28 Feb 2004 10:58:47 +0100 (MET)
Hello Jason!

> Do I need to take the above steps, create a new volume, copy the data
> from the existing volume into the new "truly replicated" volume, drop

An intermediate volume is not really necessary, you can copy the data to
any storage area, to a local disk or somewhere else (make a tar archive
and in some way remember the acls for all directories...)

> the old volume, create another new replicated volume with the name of
> the original, and finally copy the data from my "new" volume back to my
> "original" volume? or can I rename the "new" volume to the "original"'s
> name after dropping the original?

Iirc Jan said once that there is a volume rename operation but that it is
implemented "halfhearted" so that it is broken (never having been used).
It renames replicas to the same name, which is wrong...

So the best bet is to save-drop-create-fill ...

By the way, there is a reason for a volume rename operation to be
unreliable. It _is_ confusing, that the volume name space is used
for different things - like volumes vs their underlying replicas.

A mount point can refer to a replicated volume, a corresponding backup or
clone (which are [going to be] the same internally?) or one of read-write
replicas. Of course, all of them have different names, but there is
no enforcement (?) on the names, still there are assumptions on what they
have to be.

Imho parts of the name space should be reserved for "derivative volumes".
It would be easy if we had an otherwise reserved separator like "/" for
filenames... but we don't. A dot is used as an informal separator, which
is not satisfactory.

Right now nothing prevents me from creating a volume "data.1",
but then at a later point I cannot create a doubly replicated volume
called "data" as one of its replicas should be called "data.1"

At the very least we should state that we explicitly reserve some names
like  "*.[0-9]" and "*.backup"
and let the volume management tools follow the convention, not the
administrators make contradictory ad-hoc decisions...

(still there will be some complications, like creating a volume
"-a-long-name-up-to-31-character" and getting broken replica names as
the volume name cannot exceed 32 chars... do we want to proclaim the
maximum volume name length to be just 25 chars, to count for ".backup"?
I'd rather reserve a shorter ".b" for backup volumes :)

Another approach would be to split the namespaces, by introduction of
different kinds of mount points, one for regular volumes, one for
replicas, one for backups... as well as different kinds of volume
operations which can take volume name as a parameter... it would be
"right", but more complicated and hence also confusing :)

Received on 2004-02-28 05:04:06