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?)

> btw. it looks like the clone operation always appends '.readonly'. I'm
> not sure why, readonly state is defined by a flag, not naming.

Yes, it seems unnecessary - when we choose the name ourselves anyway.
And it is bad as it uses 9 positions of our precious possible 32 :)

> No regular volume names could end in .backup, which will not screw up
> the backup process, but will cause problems during volume lookup.

> > My guess is that all that is needed is a minor change in volutil?

> Probably, it will have to test for conflicting names, and if there is a
> conflict if that volume happens to be the previously cloned backup

As conflicting names can create a problem now too, volutil should make the
check anyway, shouldn't it?

> 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! :-)

Best regards,
--
Ivan
[having lost a volume replica today because of a server crash at
volutil backup operations, possibly just indirectly but still... that code
needs some attention
- fortunately I could recreate it from the other replica, without having
any downtime at all! :-]