> Our thought about this was that these extra uses could come along later.
> The extra space has a flags field. We didn't expect 32 extra things to
> come along - if we're trying to cram that much into an inode, we have bad
> feature creap.

Oh no, this is exactly the opposite of what I meant.   You've already
said that you're going to leave the first 128 bytes of the i-node
alone.   I don't think we all agree that's the right thing to do.
You say:

> These flag bits would indicate what extra goddies are there, like
> Y2038-safe dates

This doesn't belong in the opaque data field - that would simply be a
duplication, and wouldn't work if you needed the opaque data for
anything else, thus rendering the opaque data useless.   Fixing the
times on the inode pretty much requires a change in the existing inode
structure.

> support for more than 32-bits worth of blocks (I think that was one
> of the things Perry mentioned, but I'm not sure if our indirect
> block system would support that?)

This is another thing that doesn't belong in the opaque data.

> support for acl's, etc. As features arrive, dump, restore, ffs, &
> friends get taught about them.

That's great, but the opaque data isn't a place where any of these
features can go - you already have a use for the opaque data.  Any one
of these uses would prevent the other uses.  This simply doesn't make
sense.

> That way we don't have to decide now what we want to do, we leave space
> for future growth. Also, we don't have to wait for these features to be
> defined to move forward. :-)

Unfortunately, I think we do have to wait.   Please don't take this
the wrong way.   I think you're on the right track here.   I just
think it's premature to cast what you have in concrete right now.
The pressure of having to decide on this prior to 1.4 is just not
reasonable.

			       _MelloN_