On Jun 19, 2007, at 3:27 PM, Adam Megacz wrote:


Has anything changed in the last year since this?

  http://www.openafs.org/pipermail/openafs-info/2006-July/022917.html

In particular, could somebody make a statement about exactly what
vldb/volserver operations "vos clone" and "vos shadow" perform, at a
very low level?  This would be a helpful step towards understanding
how to use them safely.

Dan Hyde can answer things on shadows better than I, but I can talk a fair amount about clones.

We experimented :-) with clones. We found that you can create up to four clones without any particular difficulties. The same restrictions apply as would to your .backup volumes - ie, have to share inodes and therefore reside in same server and vice directory, vanish if you move the parent volume to another server, etc, etc. They show up in the vldb, and work perfectly fine as a more persistent version of the .backup volumes. They persist until you delete them (or move the parent volume).

If you create more than four you start interfering with other afs functionality. As best I recall, the real answer is that a volume in a namei filesystem can have seven clones, but three should be held in reserve so that afs operations like move, copy, backupsys, etc continue to work.

Unlike the .backup/etc clones that afs uses as working sets, you chose the clone names. We called them vol.clone1 .. vol.clone4, but could have named them vol.200701, vol.200702, etc as monthly snapshots.

We found no problems caused by the creation of additional clones in a production file system.

In fact, our biggest problem with clones is that we can't make as many as we'd like. If I could make, oh, 100 clones I'd do away altogether with our file restore system (what you might call 'backup') and just do disaster recovery. If anyone's played with them on non-namei filesystems, we'd be very interested in your experience.

Steve
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to