Subject: Re: as long as we're hitting FFS...
To: Julian Assange <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 03/25/1999 11:55:26
On 25 Mar 1999, Julian Assange wrote:
> Bill Studenmund <firstname.lastname@example.org> 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.
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.