[OpenAFS] Re: Vos functions and clones and shadows

[Marcus Watts]

Adam Megacz <megacz@cs.berkeley.edu> writes:
> Date:    Tue, 26 Jun 2007 14:41:12 PDT
> To:      openafs-info@openafs.org
> From:    Adam Megacz <megacz@cs.berkeley.edu>
> Subject: [OpenAFS] Re: Vos functions and clones and shadows
> 
> 
> Derrick J Brashear <shadow@dementia.org> writes:
> > the problem is it lives in the volume group of its parent, so it's a
> > halfling. parent's gone, but... yeah, like you say
> 
> While we're on the topic, what is the reason for having volume groups
> in the first place rather than just having a reference in the volume
> header saying "I am a backup volume for volume XYZ" to establish
> volume relationships?
> 
> Is the "volume numbers share all but the last three bits" criterion
> visible to the cache manager, or is this something that could be
> altered just on the servers and admin clients (vos, bos, etc)?

Cow.  They aren't really 3 separate discrete volumes.
They share data, and that means on the fileserver, the logic
knows this at a deep level.

The cache manager doesn't know any of this.  Volume numbers
are completely arbitrary to it.

Incidently volume numbers don't share "all but the last 3 bits".
If that were true, volumes would be separated by 8 not 3.
In very old AFS, volume IDs were assigned on the fly and
might vary much more randomly, but this hasn't been true
for a long time and volumes that old seem to not behave
quite right in openafs.  The extra cow copies that
Dan and Steve are creating do have "random" volume ids
that could vary widely (actually they are assigned using a
counter in vldb...).

The "all but the last 3 bits" bit has to do with some of
the internal book-keeping logic inside the namei fileserver,
where it has clever bitpacking for stuff.  This is mostly
used for "per-inode" data, such as the stuff in the link table.

The inode based fileserver does not have the "last 3 bits" problem,
and could have many more cow copies.  Too bad it's such a hack.

				-Marcus