On 25 Mar 1999, Julian Assange wrote:

> Bill Studenmund <wrstuden@nas.nasa.gov> writes:
> 
> > That's why the extra space has a flags field. :-) If you want to use that
> > 96-bytes of space for something else, then you have space to indicate that
> > use. All you have to do is just tell ffs to not allow storing of opaque
> > data on top of it. No big loss as I don't see as symlinks are supposed to
> > just point somewhere else - they aren't real files. :-)
> 
> Flags field or not, this idea is simply impoverished. It might suit
> whatever application you are using it for *perfectly*, but it's a hack
> and not a solution where other problem domains are considered. If you
> want this type of feature I strongly suggest a type:value chain
> system. If you are concerned about the amount of work involved, limit
> the number of tuples *by imlementation* (not design, and not api) to
> whatever can fit inside an expanded inode, as this leaves you with the
> ability to transparently change implementation specifics without
> modifying the again modifying the api, or the inode data structure size.

Julian,

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.

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

Leaving room for someone to ADD a resource manager is fine, but that's not
what we have in mind.

Take care,

Bill