[OpenAFS] status of "vos clone/shadow"?

Steve Simmons scs@umich.edu
Wed, 20 Jun 2007 15:30:14 -0400


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