> Also, what do you do if the agregate of stored info is more than say the
> 128 bytes we're proposing growing the inode? Answering this question is
> a big part of the reason why I think the general solution is hard. :-)

The kernel returns ENOSPC.   Same thing that happens when you fill a
disk - just sooner.   In the sense that you mean general, there are no
general solutions.

> Also, userland would need to have a library to grovel this. I'd assume
> we'd then want to just turn the full inode growth over to this storage. 
> For one thing, the ACL pointer would go in here, and dump would need to
> know how to find it. Plus we have userland code which needs to look at the
> on-disk fs image.

I think the ACL pointer is actually a poor example, and you debunked
it in a previous message.   If FFS is doing the ACL, it might as well
be a first-class object.

> If you're going to do this, I'd vote for 16-bit magic and 16-bit length.
> Also, this design would need to keep everything in a fixed order so that
> the parser can figure out what's going on.

Dude, the field is only 96 bytes - why do you need to store a 16-bit
length?   Why does it need to keep everything in a fixed order?

> No, not necessarily. All our layer cares about is if its calls to set &
> store data work on the fs it's mounted over. If you (or someone else)
> come(s) along and add a broader API, which can support all sorts of stuff,
> including the implicitly-96-byte ops, then our layer will be happy. :-)

I think you should simply use an API in which you explicitly provide
the length, even though you'll always say 96.

			       _MelloN_