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

Adam Megacz megacz@cs.berkeley.edu
Sat, 23 Jun 2007 10:51:59 -0700

Side note: I found that if you "vos remove" a volume that has a clone,
the clone will not be deleted automatically (ie unlike backup
volumes), but the vldb does seem to get confused: the "dangling clone"
can't be deleted by name; only by volid.  I don't know if this is a
bug or not.

  - a

Steve Simmons <scs@umich.edu> writes:
> 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

PGP/GPG: 5C9F F366 C9CF 2145 E770  B1B8 EFB1 462D A146 C380