[OpenAFS] Automatic move of volumes
Thu, 25 Oct 2007 18:52:08 -0400
On 10/24/07, Steven Jenkins <email@example.com> wrote:
> On 10/24/07, Derrick Brashear <firstname.lastname@example.org> wrote:
> > >
> > > It has _everything_ to do with namespace management. In absence of
> > > better tools, people are using vos release to do just that. Note that
> > > vos release isn't a bad tool; it's just being stretched beyond its
> > > design because people need a way to do versioning of their namespaces.
> > you want to dump and restore volumes. that's ugly. it's not a namespace
> > issue; you want versioned volume clones.
> dump/restore is just a mechanism in lieu of a volume copy operation.
> Versionized clones could be interesting in this context, but I would
> prefer to stay away from that approach as it makes it harder to
> recover & see changes in the base volume. I think having one RW per
> 'generation' of ROs is reasonable.
I agree that having one RW per generation is very useful. Ideally,
I'd like to see a volume group become a more flexible container which
contains an arbitary inheritance tree structure. For instance, it
would be useful to allow creation of addtional forked RW volumes
within a volume group. This would, in effect, give us the equivalent
of a CVS branch tag for a volume. Obviously, the existing model where
a volume name is a tightly coupled 1:1 mapping onto the volume group
is a limitation which would need to be lifted. But, there are other
reasons why making the name map more flexible would be beneficial
(e.g. providing useful names for infinite backup clones, etc.)
> With versionized clones, you would need to create a mechanism to have
> potentially infinite numbers of clones, with arbitrary generation
> identifiers (eg, some would be ok with '1', '2', ..., but some would
> want 'alpha', 'beta', ..., or 'dev', 'prod', etc). IMO, that's better
> done outside of the volume itself.
Not sure I agree. Providing this type of metadata in the volume
management system itself has value (provided it's done in a typeful,
standardized manner). For instance, if we ever integrate an automated
volume migration/balancing system, we will want to access this type of
information to prioritize where certain volumes are stored.