On Sat, May 03, 2003 at 07:14:11PM +0200, Ivan Popov wrote:
> On Sat, 3 May 2003, Jan Harkes wrote:
> > Although they are mostly identical, there is one distinct difference
> > between backup and clone volumes. Backup volumes have a stronger linkage
> > to the parent which makes incremental backups more efficient. This is
> 
> Ok, it looks like cloning is approximately the same as throwing away
> the old backup volume and creating it from scratch. Right?
> (generally why do we need a "clone" operation? except for that freedom to
> choose the resulting name? is it just an artifact or is there some
> semantical difference I am missing?)

Clones were used by AFS for readonly replication. The backups seem to
have evolved as an extension on the clone operation and makes the
operation a lot faster.

> > volume. Hmm, perhaps this could somehow unify backup and clone a bit
> > more.
> 
> I am looking forward to learn what is that differs between a "backup" and
> a "clone" and why we need both! :-)

Backup is identical to clone (and probably uses a mostly the same code)
if the 'backup volume' doesn't exist yet. If the backup already existed
it only deletes/reclones changed objects, which is more efficient.

So technically we don't need clone, because if the new volume doesn't
exist 'backup' does the same thing. And it might be nice to be able to
resync a previously cloned volume with the same efficient method that
backup is already using.

On Sun, May 04, 2003 at 01:21:43PM +0200, Ivan Popov wrote:
> (see also http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2002/4202.html)

I still have to look at the actual backup and clone implementations. But
if backup and clone 'combine forces', something like the following might
work.

    /etc/cron.daily/coda:
    volutil clone <volume> <volume>.daily

    /etc/cron.weekly/coda:
    volutil clone <volume> <volume>.weekly

    /etc/cron.monthly/coda:
    volutil clone <volume> <volume>.monthly

(in your case you could use <volume>/daily or something weirder)

'volutil backup' could simply alias as 'volutil clone <vol> <vol>.backup'.

I'm not entirely sure why we need a separate 'lock' operation, does
anyone with AFS experience know if there is some reason for that?
Considering that backup implicitly unlocks, shouldn't it also just
implicitly lock?

> If we loose/recreate a r/w replica because of a disaster or if we just
> change volume replication (impossible yet but according to Jan it is
> feasible to fix), then we do not have any backup volumes == data history
> connected to the newly (re)created replica.

Ah, but logically there is no 'history' for a newly created replica. I
don't think that it is necessarily realistic to allow someone to
'rewrite history' by attaching previously made (random) backup volumes
to a new volume.

> I am curious if we would gain anything by defining a new operation,
> "ensure replicas consistence", like

You're talking about server-intiated resolution as opposed to our
current client-initiated resolution. Thread lightly, I heard that there
is probably some form of IP in that area.

Jan