Subject: Re: dinode: di_spare
To: Bill Sommerfeld <firstname.lastname@example.org>
From: Darren Reed <email@example.com>
Date: 12/02/1997 15:29:54
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
> 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 ?