Pavel Cahyna wrote
> On Wed, May 03, 2006 at 08:49:10AM -0700, Bill Studenmund wrote:
> > > What have subfiles to do with ACLs?
> >
> > Where do you think we put them? :-)
> >
> > As Elad noted, we need a STRONG way to associate the ACL with
> the rest of
> > the file, and subfiles-for-storage are a good option.
>
> Subfiles are intended to be opaque, not interpreted by the kernel. At
> least that's what I got from Gordon Waidhofer's posts and presentations on
> this topic.
>
> Also, are you aware of any other system where ACLs are mapped to subfiles?
>
> Aren't extended attributes a better option?

Jason Thorpe wrote
> Yes.

In principal, I concur with Jason. ACLs are
(extended) attributes.

Bill's conjecture that something subfile-like may
provide on-disk representation has merit. Both NTFS
and Solaris UFS do something like this.

One must separate the idea of semantics and API
from the idea of on-disk representation.

Subfiles are opaque and arbitrary sized.
(Extended) attributes are meaningful and
are acted upon by get/set. Please see page 51 of
http://nasconf.com/pres04/waidhofer.pdf
for classification of subfiles and attributes.

The same presentation shows how some
different file systems handle on-disk
representation. Implentations can influence
semantics, and weaker implementations end
up requiring heavy address or being abandoned
altogether.

I believe getxattr()/setxattr() is the right API
for (Extended/New/Legacy) attributes. Attribute
manipulation is becoming more akin to ioctl().

For example, there is contemplation of operating
on both POSIX ACLs and NFSv4 ACLs through getxattr()/setxattr()
and the right thing happens whatever the underlying
ACLs are at the time. To be clear, I can ask for the
NFSv4 ACL on a file system that is using POSIX ACLs.
Or I can set the POSIX ACL on a file system that is
using native NFSv4 or NT ACLs. NFSv4 servers/clients
have to do this translation anyway, so why not incorprate
it in a way that makes things easier
for applications.

Regards,
	-gww