Given a further response (which I've unfortuantely deleted) indicating
that even the expanded big-inode structure wouldn't be large enough to
contain ACLs, I wonder why you chose to separate ACLs from Opaque Data?
And why restrict the access to and use of Opaque data to a layered file
system?  Why not applications, too?

I'm thinking back to the good/bad old days of VAX/VMS, where there was
an arbitrary procedure for storing and retrieving ACL data associated
with a file.  The ACL data was, IIRC, organized into some sort of Record
oriented structure, with a type and length field at the front.  A large
portion of the type field's range (half of it, IIRC) was reserved for
"Application Specific" data (ie, Opaque stuff), while the other half was
reserved for use by the OS and File system (ie, ACLs).

Now, please don't get me wrong - I know that if I wanted to run VAX/VMS
I could go out and buy an old VAX :) - but doesn't it seem reasonable to
have a single set of "FS Extension Data" with a single set of access
semantics?  Thus, it would be possible to use the entirety of the new
extended inode space for an ACL if the user didn't have his/her own
opaque data, and the user/application could use the entire space for
Opaque data if there weren't any "true" ACLs.  And a single mechanism
for identifying where "continuation" data, be it ACL or Opaque, could be
created.  And since that other, deleted message implies that you're
going to have to teach ffs how to process ACLs anyway, how much more
difficult will it be to teach it to ignore the User-Defined subset of
the ACL/OpaqueData type space?

I really don't want to start a flame war here (looks like we've already
got enough fuel on the fire, anyway), so if I'm totally off base, please
feel free to let me know and I'll shut up.  But this seems like such a
major extension/enhancement to ffs that I'd really like for all of us to
get a chance to make sure that we really DTRT, and in the Right Way.

On Tue, 23 Mar 1999, Jason Thorpe wrote:

> On Tue, 23 Mar 1999 13:25:42 -0800 (PST) 
>  Paul Goyette <paul@whooppee.com> wrote:
> 
>  > Is the vnextops interface going to be sufficiently general to store
>  > (pointers to) arbitrarily large amounts of "opaque data" per file?
>  > Where would this info be stored, in "continuation inodes"?
> 
> If an application (say, a layered FS) wanted to store additional
> opaque data, perhaps it allocates a new file, and stores a pointer
> (via inode number) to it.  Userland applications could do this as
> well.
> 
> Really, vnextops is orthogonal to the opaque data storage.  It's being
> used in the upper layer that Bill is working on (a data migration layer)
> for other things.  Hence the separated "generic" vs. "fs specific" namespace.
> 

--------------------------------------------------------------------------
| Paul Goyette      | PGP DSS Key fingerprint:   | E-mail addresses:     |
| Network Engineer  |   BCD7 5301 9513 58A6 0DBC |  paul@whooppee.com    |
| and kernel hacker |   91EB ADB1 A280 3B79 9221 |  pgoyette@juniper.net |
--------------------------------------------------------------------------