Subject: Re: Large inodes for ffs
To: Chris G. Demetriou <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 03/23/1999 18:52:00
On 23 Mar 1999, Chris G. Demetriou wrote:
> Bill Studenmund <email@example.com> 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
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
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
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
> 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