In some mail I received from John Kohl, sie wrote
> 
> >>>>> "JS" == Jonathan Stone <jonathan@DSG.Stanford.EDU> writes:
> 
> JS> Matthew Jacob <mjacob@ns.feral.com> writes:
> 
> >> This is a pretty interesting idea. I'd like to point out that there's
> >> a performance penalty in this (if I understand what you're proposing)
> >> while the implied 'spare' usage allows NAS (amongst others) to directly
> >> use (locally) the spare fields for HSM.

What is NAS and HSM ?

> JS> Are these by any chance the same inode bits AFS steals?  If so, that
> JS> would tend to interfere with any *BSD-specific usage, at least at many
> JS> academic sites.
> 
> In theory, these uses could collide.  However, (a) the AFS modules for
> NetBSD do not include server volume support, and (b) even if it did, AFS
> would have to use something other than the spare fields since there are
> not enough spares for AFS's needs in 4.4BSD FFS.

Do you (or anyone else ?) have any more detailed information on what AFS
does here ?  I do know that SunOS 4 uses the last 16 bytes in their
"dinode" structure for storing values used in the kernel only:

                /*
                 * XXX - the disk spares were used to avoid changing
                 * the size of the incore inode in a minor release.
                 * Fix for 5.0 release.
                 * Also remove the code in iget, iupdat that clears them.
                 */
                long    ic_delaylen;    /* 112: delayed writes, units=bytes */
                long    ic_delayoff;    /* 116: where we started delaying */
                long    ic_nextrio;     /* 120: where to start the next clust */
                long    ic_writes;      /* 124: number of outstanding writes */

but that shouldn't be a problem - it's an earlier verison of `UFS' (0),
which already has certain differences to UFS versions 1 and 2.

Darren