1) r/w volumes pause all activity during a replication release 2) backups need to show only the blocks changed since the last backup (instead of entire files) 3) (it seems) volume releases copy the entire volume image instead of the changes since the last release
It looks like all of these issues would be solved in part or completely with the introduction of "Multiple volume versions" (as listed on the openafs.org web site under projects).
1) would be solved by creating a clone before a release and releasing from that.
That already happens. But the cloning operation takes time, and the source volume is indeed busy during that time.
2) would be solved by creating a clone each time there is a backup and comparing it to the previous backup clone. and 3) would be a similar process with volume releases.
This is not a bad idea. Of course, you still have problems if the start time for the dump you want doesn't correspond to a clone you already have, but that situation can probably be avoided in practice.
Of course, there's a reason that "multiple volume versions" is not done, and it has little to do with the ability to have multiple clones. The volserver _today_ supports up to 7 volumes per volume group on namei servers, and quite a few more on inode servers. You can use 'vos clone' to create additional clones, but be careful unless you really fully understand what you're doing. Under normal circumstances AFS will never use more than four volumes per volume group (the R/W master, a backup clone, either a permanent RO clone or a temporary release clone, and finally a temporary move clone when the RW volume is the source of a move or copy).
The hard part of the feature listed on the roadmap is figuring out how to give clients the ability to refer to multiple versions of a volume, so there can actually be a user-visible multi-level snapshot feature.
-- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA
_______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
