[OpenAFS-devel] vos dump busying out the volume while dumping...

[Neulinger, Nathan]

I'm not sure that would really be necessary to do the additional
incremental. When you do a dump, you're picking an abitrary time to do
the dump, shouldn't matter if it's the dump from the clone or the dump
from the RW - since volume is locked busy during the time you make the
clone, it should yield the same result.

Without -clone:
	Busy RW
	Dump header
	Dump data
	Unbusy RW

With -clone:
	Busy RW
	Create clone vol
	Clone data from RW
A	Unbusy RW
B	Busy clone
	Dump header from clone
	Dump data from clone
	Unbusy clone

Unless something changes in the clone from A to B, which shouldn't be
possible, the end result should be identical I would think.

If I'm missing something obvious here, please point it out.

I've got the code written (will send a patch momentarily) - and it's
very nice result. The parent volume is only locked for the period of the
clone operation, and not the full dump.

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Derek Atkins [mailto:warlord@MIT.EDU]=20
> Sent: Wednesday, October 23, 2002 11:40 AM
> To: Neulinger, Nathan
> Cc: openafs-devel@openafs.org
> Subject: Re: [OpenAFS-devel] vos dump busying out the volume=20
> while dumping...
>=20
>=20
> "Neulinger, Nathan" <nneul@umr.edu> writes:
>=20
> > Under normal circumstances, I'd always dump the .backup or .readonly
> > volume, but I am looking at the possibility of doing fairly frequent
> > incremental dumps of volumes, and had an idea about it.
> >=20
> > Currently, vos dump starts a transaction on the volume you specify,
> > marking it as busy while that entire transaction is running.
> >=20
> > What about adding a "-clone" option to vos dump syntax that would
> > operate very similar to how the vos move behaves.=20
> Basically, clone the
> > source volume, do the dump from the clone, and then delete=20
> the clone.
>=20
> Sounds good in theory.  You would have to change the dump format
> slightly because you would need to have the full dump from the clone
> and then the incremental dump from the changes to the RW since the
> clone was made.
>=20
> > Comments?
> >=20
> > (Before you suggest just running vos backup, I'd rather not=20
> replace the
> > existing .backup volume during the day, since we publish=20
> that it is a
> > backup from last night.)
>=20
> -derek
>=20
> --=20
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord@MIT.EDU                        PGP key available
>=20