> A type:value chain strikes me as just way too space inefficient and time
> inefficient a thing to stick in the inode, especially for essentials of
> how the fs accesses the node. We don't need that kind of flexability, and
> the overhead is too expensive.

You have 96 bytes.  You are already going to consume four with a magic
number.  Why not consume another one with a length?  Indeed, if you're
worried about space, enforce an implementation restriction that the
magic number be 24 bits and the length 8 bits, and then there's no net
loss.  Don't restrict the length to 8 bits in the API - just return an
error if there's no space to stuff the bits.  If an application or
layered filesystem needs to store something and there's no space, it
returns an error on the operation that caused the store to be
attempted, or works around the lack, depending on the implementation.

As far as I can see, this gives you what you want, and shuts us up, at
least WRT the notion of sharing the field.   We still are likely to
use if anybody else comes up with an application for these bits that
consumes a lot of space (and I can certainly imagine such an
application) but at least it's better than nothing.

BTW, is there some particular reason not to make the inode a _lot_
bigger?  Why not jump straight to 512 bytes, or even 1024 or 2048k?
I'm not being entirely facetious here - having a per-inode dumping
ground with a small but reasonable amount of space would be a big win.
If you made the inode 512 bytes, that would give you 256+96=352 bytes
in which to store arbitrary attributes, which would probably be enough
in most cases.  This may seem like a lot of space to consume, but the
inode has been 128 bytes for quite a while, and in that time the
average system disk has more than quadrupled in size, so it's not as
unreasonable as it sounds.

> I think what would be much better is to teach ffs (and lfs) about resource
> forks in general. Like a cross between hfs and the NT filesystem. Like NT
> in that there's just this extra blob of data (no built-in resource
> manager), and like hfs in that there is only one (as opposed to many).

One way to do this would be to add two fields to the inode: a link
field and a magic number field.   The link field would point to
another inode, and the magic number would identify what's in that
inode.   Then you could stuff a resource fork in quite easily, and
indeed you could stuff in more than one resource fork if you wanted.
Of course, then any applicatin wanting to archive or copy the file
would have to know about resource forks, but this seems like a good
general scheme if such a capability is wanted.

			       _MelloN_