Reinoud wrote
> Apart from its on-disc structures i think it would be wise to use or at
> least study its [UDF] semantics and definitions as a starting reference
for its
> at least a coherent specification that has been `out there in the
> wild' for quite some time.

It should be included in a proposal as part of a survey. Time on
the planet is relavent, but deployment and interoperability
are weightier issues. NT, NetApp, and Solaris semantics come to mind.
And expect change.

> Interestingly it is pretty like the proposed linux/solaris mix we
> came to. I'll try to give a summary of UDF attributes/subfile
> support and handling to give an indication.
> --snip--

Nice summary on UDF model. I didn't know UDF was so clear
about time updates. It is interesting how UDF partitions
spaces based on size. The "invisible to userland" option
in space 4 entries is a good trick for very large attributes.

> Furthermore UDF preferably stores NT ACLs and UNIX ACLs (most likely
> refering to posix ACLs) in space 4 under fixed names for version 2.60+.
> This is not optimal IMHO since it thus will cost at least 2
> discblocks for
> each annotated file extra (!) They dont have to be exported as inodes
> though but still. Are NT/posix ACL's that lengthy at times that its worth
> such spillage? Big bummer is that the (lengthy?) ACL's can not be shared
> between files since hardlinking in subfiles is NOT allowed.

POSIX ACLs tend to be fairly limited size, like 1k or 2k limits.
Often smaller. NT ACLs can be a monolithic 64k data structure.
Interoperability tests (NetApp's, I think) already test implementations
to handle max ACL size. These show up at plugfests.

> If ACL's are short they prolly will also be allowed in one of the other
> streams but i haven't explicitly seen a reference to it yet. I'll ask
> around.

I saw something in SGI's notes on UDF implementation where they
compromised on the UDF "rules" for some of XFS issues related
to extended attributes especially large ones.

> The only advantage of seeing both `file attributes' and `subfiles' as a
> more generic `attribute' is that it doesn't care about what
> implementation/model is behind them.

We never care about the implementation model behind the API model.
We're not suppose to.

The trouble -- confusing attributes and subfiles -- started when
folks believe the superficial similarity would carry through APIs,
representations, and so on. It does not.

> This approach however DOES have a
> fundamental problem : it requires explicit and strict content
> definition of
> some named `attributes' to be defined and no definition for the rest!

And definition means a lot of things:
	- .h files for the API (think struct stat)
	- Canonical text representations for pax(1) encoding
	- RPC definition for NFS encoding
	- etc, etc, etc (see my presentation on nasconf)

>
> Could it be that for NFSv4 it was decided that it was too early to be
> strict and thus allowed all to be transfered thus putting the
> restrictions
> on content solely on the peers? ("left open for further standardisation")

It was weakly understood at that time. For the sake of
interoperability with NT, the OS/2 model of EAs were the
first influence. Nobody knew they were completely irrelavent.
But it was a happy accident because it put in place the
right thing for the OS/2 EA successor -- subfiles. It just
has the wrong name :)

NFSv4 attributes are extensible. That was a design point.
They are named by small integers. They are rigorously
defined. They are not opaque. That's pretty much the
duck test for attribute, IMO. Hence anything that
is opaque (subfiles) should *NOT* be called attribute
because it confuses the terminology unecessarily.

> > > Do you think we could make a standardised form acceptable? I
> could try to
> > > work out a full specification if only for *BSD and Linux...
> >
> > A solid stake-in-the-ground would go a long way. Any proposal
> > necessarily needs at bit of history including clarification on
> > the difference between attributes and subfiles, the activities
> > of Solaris, NetApp, and NT, and justification for interface
> > names. Some statement of requirements would be good, including
> > UDF/NFSv4/HFS+ issues.
MacOS should be on this list, too.
> > I would include a plea for convergence.
> >
> > After that, a pilot implementation would be good. Demonstrate
> > the adequecy of the interfaces for UDF, HFS+, and NFSv4.
> > I wouldn't count on that being adopted overnight. But it
> > would at least give folks something concrete to examine
> > and discuss.
>
> Indeed. Maybe NetBSD can fullfill that reference implementation? AFAIK we
> as NetBSD are not bound by `legacy' yet and we as NetBSD would
> get best of
> both worlds.

Yup. That's my hope.

That FreeBSD ACLs and EAs haven't been
integrated yet is a good thing. They ultimately will be the
wrong thing, and I'm quite sure FreeBSD will have a horrible
time trying to resolve NFSv4 OPENATTR and the weenie extended
attribute model that's there.

NetBSD is in an excellent position to pursue the likely
course of the file model.


Keep up the good work, Reinoud.

Regards,
	-gww