> > We decided that an inode could contain at most one type of opaque
> > (application specific) data. To do anything else would be sticking a file
> > system in a file, and that's messy. :-)
> 
> I think that's the part that troubles me the most.  It sounds like it solves
> only one problem at a time, and seems like it was designed with only one
> problem in mind.  But maybe if I knew more about it, I'd be less worried that
> the filesystem format will have to change again to support any use other than
> the original problem which motivated the design.

How is this opaque data shared between competing resource users?
What if you have two or more meta-layers? This seems to be not only
a solution to a problem that doesn't exist, but a foolish solution
at that. I'd much rather see a well thought out *scaleable* solution.
As a trivial example, one could design a system of opaque meta-chains,
the first entry of which was stored in the inode, ala inode symlink
optimisation and the rest either stored in subsequent inodes or,
preferably, in a file of their own right. Each entry could be
given a consumer id, protection flags and a length designator.
i.e a type-length-value chain. This would permit essentially
arbitary extension and consumption of file attributes and a
reasonable degree of forwards-compatability (not understanding
an attribute would simply result in being unable to apply it).

Cheers,
Julian.