[OpenAFS] Re: status of "vos clone/shadow"?
Thu, 21 Jun 2007 16:57:36 -0700
Wow, Steve, thank you very much for these detailed replies. This is
exactly the sort of explanation I was hoping for.
Is there any place from which we can get the changes you made to the
Steve Simmons <email@example.com> writes:
> On Jun 19, 2007, at 3:27 PM, Adam Megacz wrote:
>> Has anything changed in the last year since this?
>> 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.
PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380