On Sep 6, 2005, at 5:41 PM, Gordon Waidhofer wrote:

> And if there was no argument to win, would you *REALLY* think
> that was a good idea?

Huh?  The world isn't perfect.  There are different kinds of file  
systems out there, and if you want to be "fully-featured" on all of  
them, sometimes you have to do wacky stuff, like use special files to  
store certain kinds of information that the file system was not  
originally designed to store.

> To be fair, I'm quite pleased today. That there is the notion
> of "we should have both" is a kind of concession. It practically
> admits that the BSD/Linux model of "named thingy" is inadequate.
> If it was adequate, nobody would suggest both.

I don't think it's a concession.  I was never arguing that subfiles  
weren't a good idea.  I was, however, arguing that extattrs were not  
a BAD idea.  I think each of them has their place, and I still  
fundamentally think that subfiles are not necessarily the best place  
to store things that are "extended attributes" of a file from the  
perspective of the file system implementation.

> NetBSD has no significant investment or deployment of what
> is (effectively) admittedly inadequate. So why do it?

A good reason to do it is compatibility with existing deployed UFS  
file systems.  Another good reason is, as I've already said, extattrs  
clearly define something as a "file attribute" as opposed to "just  
another place to store file data".  Consider the distinct  
capabilities that might be expressed in an ACL:

- "read data"
- "read attributes"
- "write data"
- "write attributes"
- "read security information"
- "write security information"

Now, tell me -- what is a subfile?  Is it data?  Is it attribute  
information?  What about storing security information?  Do you now  
have magic subfiles?

I think subfiles have their place.  Consider a movie file that has 2  
data forks -- one for video, one for audio.

> Both is not necessary. Just have a way to add bona-fide
> attributes (like ACLs) internal to the underlying file
> systems. Use getxattr() API (ala Linux) to manipulate the
> new bona-fide attributes. No need to expose the storage
> mechanism for attributes to the API.

I don't think that the current APIs expose the storage mechanism at  
all.  In fact, consider HFS+ in 10.4, which even overlaps the two in  
certain circumstances... HFS+ in 10.4 supports extended attributes  
natively.  It also supports subfiles (the resource and data forks)  
natively.  There are a couple of special extattrs  
("com.apple.ResourceFork" and "com.apple.FinderInfo") that can be  
used to get/set the data in the file's resource fork and Finder info  
(the former which can also be opened as a named fork, i.e.  
"file/..namedfork/rsrc", which in principle could also be opened with  
openat()).

It puzzles me that you remain focused on NFSv4 in this discussion.   
We also need to be concerned about the actual disk-backed file  
systems that might be served out by NFSv4.  Like it or not, those  
file systems might not support all of NFSv4's groovy features (like  
subfiles, for example).  There are a lot of lumps to go around... how  
many and what kind of APIs we have to provide access to certain kinds  
of file information is only one aspect.

-- thorpej