>> A lot of other AFS ports seem to use di_gen (or similar) for vicemagic.  A
>> quick grep through the ufs tree doesn't show that it's being used; looks
>> like it's okay.
>
>di_gen should be used as the NFS "generation number", incremented each
>time an inode gets recycled..  It's been a while since I looked at the
>fileserver in detail, but I believe that one of the *other* vicep?
>fields is used in exactly the same way.

Right, but since we're not using NFS, it's safe to use di_gen for AFS in
this case (and in fact, since most other ports _do_ use it, then it makes
sense?)

>> ... but let's pretend we're not going to run LFS underneath AFS.
>
>Why not? (well, other than the fact that there isn't an fsck for LFS
>yet....)

You mean, besides the fact that LFS doesn't work? :-)

>> So, does this make sense?  Or did I miss something?
>
>Well, the approach taken by AFS ports on systems which don't have
>sufficient slush fields in the inode is to stuff the additional fields
>into a separate file indexed by the inode number; that's probably
>safer, albeit slower..

Could you point me to ports in which this are the case?  I would be interested
in looking at their approach.

One thing brought up to me was that you could use the U of M's
"Multi-Resident" AFS and just use FFS as a single residency.  We've been
experimenting with MRAFS here, and while we've had a few problems with it,
it seems like it works pretty well.

--Ken