On 23 Mar 1999, Chris G. Demetriou wrote:

> Bill Studenmund <wrstuden@nas.nasa.gov> writes:
> > Also, the opaque data starts with a magic number, so that different
> > applications (users of the data) can tell if a node has their data or not.
> > Also, the magic numbers are reserved both normal and byte-swapped, so that
> > applications can tell if the opaque data is theirs from an opposite-endian
> > machine. :-)
> 
> So, basically, to draw several things from this:
> 
> * You can stack file systems which use the opaque data... but only one
> deep!

The only way I see to support multiple users of opaque data would be to
build something like the MacOS resource manager into ffs. That sounds
REALLY gross to me. I like the resource manager, but it is not our intent
to stick an fs inside an ffs file. :-)

> * You'd better make sure you don't try to stack a single underlying
> file system under multiple users of opaque data, or else things may
> become Very Confused and/or unusable in any meaningful way.

True. But we don't envision opaque data as beig a panacea. It's intended
to let you make a stacked fs which can maintain state. :-)

> * You can bypass the entire meaning of the opaque data by just
> mounting the file system without mounting the 'overlay' which uses the
> opaque data and then modifying the opaque data in various ways.

Given that opaque data is intended to be state for stacked fs's, I don't
see how we can get around this point. :-) Only the stacked fs knows the
semantics it has in mind.

> To me, this screams even more strongly that a generic vnextops() (or
> whatever) is wrong, and that the right way to use the opaque data is
> have it marked as 'opaque' in the generic ffs inode code, but provide
> variants of FFS which do various things with it e.g. acls, provide
> user-settable data, etc., and _enforce_ in the kernel, that only users
> that understand the 'nature' of the opaque data can access the FS via
> the file system interface.

Why are you so angry with vnextops? All it does is permit programs to ask
the fs to do things to a file's vnode. And to protect against syscall
profusion.

Also, one thing I didn't make clear is that I don't forsee vnextops having
the split command space of ioctl. :-)

I do not envision acl's using the opaque data. I don't think that acl's
would fit (or that we want to limit them to fitting) in even a large
inode. My thought was that ffs would get taught about acl's. The extra
space in a large inode (outside of the opaque data) would be where hooks
for acl's would go.

acl's shouldn't rely on a layered fs for utility - they will need to be
built into ffs. Just because I mentioned having the same syscall that
accesses metadata do acl's doesn't mean that they are stored in the same
place. :-)

Also, where in the kernel should we enforce access to the opaque data? To
ffs, it's just a 96-byte blob in the inode which might or might not be
there.

> i.e. have a 'user-available opaque data FFS' variant (which will let
> you provide something like vnextops(), but in a less gross way 8-),
> have an 'ffs with acl' variant, etc., that vary only in their handling
> of the opaque data and which enforce 'ownership' of the opaque data on
> a file system.

My thought is that storing state for an overlay fs is orthogonal to having
acl's. :-)

Take care,

Bill