> I stoped pushing for it to go into 1.4 a while ago.

Cool.   I'm sorry I missed that and made a pain in the ass of myself.
:'}

> What I think I'm still arguing is that: we were proposing a large-inode
> variant of the current ffs implimentation (more accuratly of the ufs
> implimentation), NOT a whole new fs, and that we are providing a
> framework for a lot of new stuff. As not everyting can be decided now, we
> left room for future growth.

Okay.   It seems like there are three classes of objections generally:

1. The opaque data area is inherently application-specific because
   there's no mechanism for sharing it, and also because it's arguably
   too small to share.

2. The new API for accessing the opaque data area seems unnecessary.

3. There are other things we ought to throw into the inode while we're
   at it.

4. Maybe we ought to store the filesystem metadata in network byte
   order so as to enhance plug-and-play.

I proposed a couple of ideas to deal with (1) in a different message,
as has Julian.   (Of course, I like *my* ideas better... :')   It
sounded like you'd come up with a way to resolve (2) with fcntl -
true?

Some ideas have been floated for (3) as well.   Unfortunately, (4) is
more of a judgement call than anything else, and therefore looks like
something that either comes down to a vote or a fiat.

			       _MelloN_