Subject: Extended Inode Information
To: None <tech-kern@NetBSD.ORG>
From: Darren Reed <darrenr@cyber.com.au>
List: tech-kern
Date: 12/03/1997 17:09:44
Ok, some more details on ideas I've received/had about this idea of using
the di_spare[2] space in the inode stored on disk.

One person mentioned that it should be done so that only one 32bit longword
is used and that is to store the actual inode address of the `next inode'
and its type would be stored in-block.  The advantage was if you changed
that EIII (Extended Inode Information Inode), you would have to find all
those referencing it by a brute force search.  Whilst I did not have this
sort of association in mind at the time, it has merit and cannot be
dismissed.  Hopefully we can make it use the same spare 32bit longword as
AFS does for its magic number, adding another "invalid" value to those not
allowed as an EIII reference (others would be 1, 2, and anything else
referring to an actual file or directory).

So far, I can only think of 3 (or 4) fields which must be in the EIII: the
next EIII, the number of references and the current one's type.  The type
I originally thought of as a 32bit value, but can see that it might be
useful to have some generic properties/flags, such as "this type can only
be present once" for associating an executeable with a data file.  I'd
like to make available at least 16 bits for these sort of flags, but I'm
not sure whether it is then wise to limit the number of different types
to a 16bit number (having split the 32bit value in two).

Presently, I don't see any reason to actually implement it in UFS itself,
maybe a EUFS (Enhanced UFS :) which layers on top of it (better for testing
too).  I'm not keen on making it a general VOP-like operation.

Finally, there needs to be some way for user programs to interact with
this.  So far, I have the following operations as being desirable:

- get (next) EIII
- replace EIII
- add EIII
- insert EIII
- clear all EIII information

These would ideally be done through something akin to an einodectl(2)
system call.

Darren

p.s. sorry for the EIII acronym, suggestions for a better name & acronym
     are invited :)
p.p.s. more comments definately welcome :)