In some mail I received from Bill Sommerfeld, sie wrote
> 
> There are five 32-bit longwords used by AFS.
> 
> AFS adds an additional level of indirection.. logically speaking the
> ilist is sort of two-dimensional ("volumes" within the partition in
> one dimension, inode within volume on the other..).
> 
> One of them is used analagously to the file generation number added by
> Sun for NFS.

The file generation number seems to have found its way into the "standard"
UFS inode structure now too (di_gen).

> of the other four, it appears that there are:
> 	- a magic number, 0x84fa1cb6, indicating that this is an inode
> 	managed by the AFS volume package.
> 	(this could be handled as a file attribute using the 4.4bsd
> 	attribute system; fsck needs to not do with directory connectivity
> 	checks/repairs for inodes with this attribute).
> 	- the volume number of the volume the inode is a member of.
> 	- the volume-internal node number within the volume that the
> 	  inode "lives at"
> 	- the AFS-protocol-visible data version number (used for cache
> 	  coherance).
> 
> Systems which don't have room for all of these fields on disk put one
> or more of these in an auxilliary file (which can, of course, get out
> of synch with the inode).

Well, if there was am AFS server product which ran on a 4.4-BSD based
system, it would already be using those "extra files".  I assume that
the "magic number" (0x84fa1cb6) is going to be present in one of those
two, which seems to solve the problem I was worried about :-)

Assuming they are putting the magic number there, do you know if they
use the first or second spare 32-bit longword ?

Cheers,
Darren