On Wed, 3 Dec 1997, Darren Reed wrote:

> 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).

If at all possibal I'd recomend a double linked list, that is your EIII
would also reference the inode it came from.   (that or the last inode
points to the start of the chain.  That way if something is lost fsck has
a better chance of putting it all back togather right.  (have you given
thought to what support fsck would need?  some proposals I've seen would
be transparent to fsck, some really demand fsck support)

> 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.

As others have pointed out the mac already has this concept, appearently
the amiga does.  Let me add OS/2 as anouther OS that has this concept.  In
OS/2 the concept is that a file system does not have to support this, but
if it does that is nice.  Programs often use these "extended attributes"
for temperary data that can be useful next run.  for instance perl could
do all its normal compiling, dump the compiled stuff in an EA.  The next
time it checks, if the file hasn't been modified it doens't ahve to
compile making the script faster.

This begs the question of do you want to support seperate dates for each
attribute that might exist?

I recomend that you look at the API for each OS, it makes porting easier
if you are aware of the other APIs and don't intentionaly break something
just because it is different.  In other words aim for portability if that
is possibal, though it may not be possibal.  (I don't know exactly how far
you can legally go with this though)

Henry Miller
mill0440@gold.tc.umn.edu