On Sep 6, 2005, at 9:00 PM, Gordon Waidhofer wrote:

> That was a really good post, Jason.....

I try :-)

> I believe I followed that. There is some debate. For example,
> does it make sense to store an ACL on a file if the access
> control mechanisms are not enforced? Opinions vary. I've never
> much worried about it, save for the marshalling questions.

Can you give me an example of this?  I can think of a few cases where  
this might be the case, but I'm interested in your specific example.

> You suggested mapping extattr_get/set to subfile operations. That
> might be OK. Don't know. The question was: how does a file system
> support both? I'm inferring that you're thinking of VOPs for both
> user-land extattrs and subfiles.

Yes, VOPs for both.  The two are not incompatible.  Really, you need  
separate VOPs for:

- extattrs
- subfiles
- ACLs

That's because you need the flexibility to support the native widget  
on each specific file system instance.  Note that it's not clear to  
me that you actually need a separate VOP to support subfiles ... but  
there is a question of how you represent subfiles in the kernel... a  
separate vnode?  That fits most naturally with the current  
architecture, but a subfile isn't really a separate file system  
object, in the traditional sense...

Anyway, you need separate VOPs, and here are a couple of examples why:

- It would be silly not to leverage the native ACL storage/retrieval  
mechanism on file systems such as SMB.

- Like it or not, there are file systems out there that natively  
support extattrs that are in wide use, and so supporting extattrs in  
the VFS is really necessary in order to support those file systems.

> I'm saying BSD-UFS-type extended attributes should purely be
> an implementation issue under the file system and there should
> be no VOPs to get/set extended attributes.

I disagree.  How would you propose supporting file systems that  
provide the EA primitive natively (that are in wide use; contrary to  
what you say, BSD/Linux-style EA have been widely adopted at this  
point)?

> So, let's say there are VOPs for both subfiles and BSD-type EAs.
> How does the NFSv4 server know which one to use?

NFSv4 fundamentally provides subfiles.  It should then issue subfile  
operations on the backing volume.  If that fails, it fails.  How else  
would you expect it to work today on e.g. traditional UFS?

Now, if an NFSv4 client wants to use EAs, then it is up to the CLIENT  
to simulate EAs using some mechanism compatible with the capabilities  
of NFSv4.  Maybe it chooses to use a special subfile on NFSv4.  Maybe  
it chooses something else; 10.4 uses AppleDouble files (you know,  
those pesky "._foo" files that correspond to "foo") to simulate  
Finder info, the resource fork, and EAs on file systems that don't  
natively provide those primitives.  I'm not saying that's the best  
way, but it's *a* way.

Note that ~all of this heavy lifting can be done at the VFS layer on  
the client system, and it applies equally well to local file systems.

>> A good reason to do it is compatibility with existing deployed UFS
>> file systems.
>
> I read that to be TrustedBSD and FreeBSD.

Sure.  Let's also consider that having the VOPs and APIs available  
also make it possible to be compatible with 10.4 (should NetBSD get  
an HFS+ implementation).

> Solaris is a UFS file system
> with considerable deployment and it has no such API. A shadow inode
> is used to contain FSDs. Two FSDs are defined (that I know of), both
> are related to POSIX-style ACLs. It is quite extensible and a clever
> leveraging of existing file system mechanisms (including dump and  
> fsck).
> It makes the Solaris UFS extensible. But there are no APIs to directly
> manipulate an FSD.

That was a decision on their part, and it's fine.  I see no reason  
NOT to expose the mechanism, however, to provide a more generic  
facility.

> File attributes should be subject of rigorous definition,
> including: NFS XDR definitions (marshalling and endianess
> issues), canonical text (for tar/pax 'x' records), API structures
> (operands to getxattr()), and perhaps other formal definitions
> such as XML. They should not be thought of as name/value blobs.

Balderdash :-)  Perhaps you have an application that would like to  
tag a file with some additional data that it knows how to  
interpret... maybe like a content management system... it's private  
to that application, so why should the file system not treat it as  
opaque?

> I'm unclear which way you view "attributes". Formally or as
> blobs.

That all depends on who stored the attribute, IMO.

> That is a terrific question. It was the subject of quite
> an exchange on the NFSv4 reflector about three months ago.
> No conclusion was reached.

This, to me, is evidence that the NFSv4 "subfiles and nothing else"  
model is weak.

Again, to be clear, I have nothing against subfiles.  But I don't  
think they're a solution to every problem.  I think EAs fill an  
important need.

> For now, I believe Solaris is using the access control on the primary
> data fork (ACLs or UNIX 9-bit) to apply to the subfiles. NFSv4 and the
> Solaris APIs leave the door open when there are better, more broadly
> adopted answers.

Well, Solaris has an ACL model that is roughly POSIX.1e, right?  It  
doesn't even have a way to express separate access controls on the  
attribute information.

>> I don't think that the current APIs expose the storage mechanism at
>> all.
>
> OK. This is important. I'd like to understand what you
> are saying.
>
> Are you saying the FreeBSD extattr_get/set() et al is not
> going to be a NetBSD API?

No, I'm not saying that at all.  In fact, they're already in the  
NetBSD 3.0 API (as are the VOPs, although no file system in NetBSD  
3.0 provides the back-end functionality).  In -current, we also have  
the Linux xattr API (which in turn is similar to the 10.4 xattr API;  
10.4's is unfortunately different while having the same function  
names, but I understand why the difference exists).

I was saying by that statement that I don't believe that the EA APIs  
that are out there expose the underlying storage mechanism in any  
way, shape, or form.

-- thorpej