On 10/24/07, Steven Jenkins <[EMAIL PROTECTED]> wrote: > On 10/24/07, Derrick Brashear <[EMAIL PROTECTED]> 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. -Tom _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
