Oops, forgot to cc: codalist, resending it now.

On Fri, May 02, 2003 at 11:37:53PM +0200, Ivan Popov wrote:
> I see that I can work around this limitation via "volutil clone"
> but iirc then I have to explicitely delete the ro clone each time.

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
reflected in a comment in the source.

/* General Plan:
 * Cloning a volume takes lots of effort -- tons of transactions,
 * spooling gobs of data to the log, and mucho time. It also doesn't
 * haven't to be done every time, because most of the structure of a
 * volume doesn't change. So if a backup clone exists (and was
 * successfully dumped), we can simply modify the volume to reflect any
 * possible changes to the volume.

However there is no real reason why the backup volume has the hardcoded
extension '.backup', except for simplicity. The server always uses the
backup volume id to find the existing backup volume.

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

> main ones. (Presumably they are there now? Or are regular volume names
> ending in .backup forbidden?)

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?
> An optional option could take care of naming.

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
volume. Hmm, perhaps this could somehow unify backup and clone a bit
more. i.e. make clone more efficient by using the incremental backup
stuff when the existing name corresponds to a clone we made off of the
same readwrite replica.

Jan