Jeffrey Hutzelman wrote:
On Wednesday, February 23, 2005 11:44:17 AM -0800 Mike Fedyk <[EMAIL PROTECTED]> wrote:
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.
Interesting. Is there documentation on the AFS format and how it does COW? I'm familiar with Linux LVM, so it should use similar concepts, except that doing COW at the filesystem level can be more powerful and complicated than at the block device layer.
In LVM basically a snapshot/clone just requires a small volume for block pointers, and incrementing the user count on the PEs (physical extents). How does AFS do this, and why is it taking a noticeable amount of time (also what is the AFS equivalent of PE block size)?
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.
Yes, and that is why I said it would be a specific and separate clone just for the incremental backups, so the timing isn't based on the backup clone for instance.
An interesting thought would be to clone a replicated volume on another machine that has more, but slower space than a fileserver holding the active r/w volumes and running the backups from that machine to keep load down on the r/w volume fileserver.
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.
The first step can just allow the admin to mount the clone volumes where they want them. OAFS allows you to have volumes that are not connected to the AFS tree that users see, doesn't it?
Mike _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
