Extended Attributes and how to avoid them (was Re: O_XATTR support in FreeBSD?)

[Cedric Blancher]

On 2 December 2013 00:19, Jordan Hubbard <jordan.hubbard at gmail.com> wrote:
>
> On Dec 1, 2013, at 2:05 PM, Lionel Cons <lionelcons1972 at gmail.com> wrote:
>
>> But this discussion is *not* about extended attributes, this
>> discussion is about Alternate Data Streams. Unfortunately the O_XATTR
>> discussion somehow started to cover the Linux "extended attribute
>> system", which is utterly useless in the intended use cases (as said,
>> no access through normal POSIX read(), write(), mmap(), no unlimited
>> size, no sparse data support (aka SEEK_HOLE, SEEK_DATA) etc etc).
>
> I think this discussion doesn't really *know* what it's about, frankly, because there are so many possible avenues to choose from! :-)

I thought that had been explained in detail. What's needed here is the
O_XATTR solution, which covers CIFS, NTFS, ZFS and NFSv4
functionality, Alternate Stream Garbage collection (this is the use
case I've seen in most of nih.gov's work - they use it for
application-specific index files which 'disappear' if the file gets
deleted) and POSIX api access. Since O_XATTR meets all requirements
this would IMHO be the way to go.
Additionally ZFS already has O_XATTR functionality, so the main work
would be in the FreeBSD vfs layer.

I think the work required isn't very big... maybe even the whole
discussion already exceeded the amount of work required.

> Since you brought up POSIX APIs, let's talk about that for a second.  I've worked with EAs "in the field", as it were, a lot (a LOT) and no one during my long history with them has ever demanded the ability to call read() or write() on an EA, to mmap() one, or to store sparse data in one.  I would love to know which apps actually need to do that (and why), because other than "unlimited size", none of those demands have ever hit any bug database I've had access to.

Well, where did you look?
Opensolaris's bug database is no longer public, and so are the
Architecture Cases from the days of Solaris 9, which clearly stated
the requirements and intended usage. Microsofts bug database is not
public either and even the paying audience doesn't see all details (I
can say this: Microsofts butt is currently under fire (roasted!)
because ADS is disabled by default in ReFS, which in turn caused a lot
of stirr and anger). AT&T's work is done on top of libast (which is a
platform abstraction and utility library), which either uses the
O_XATTR API, attropen() or the Win32 Alternate Data Stream API (so
just searching for O_XATTR doesn't give you the search results you'd
may expect). The other places to look at would be nih.gov and CERN,
but AFAIK both use platform abstraction libraries like libast does, so
you'd have to dig around a *lot*.

> I'm also generally not one to throw marketing numbers around in a technical conversation, but with 72 million seats and over 1 million applications (and by all means fact-check those numbers), if the ability to use EAs in that fashion were truly necessary, I suspect I would have heard that early and often.

You did notice that AT&T Research (to serve their cloud services),
nih.gov and CERN did a lot of work related to ADS/O_XATTR in the last
three years?

> I'll opine that If FreeBSD really wants to support EAs in a "useful enough" way, then the best way of doing so is to stay focused on the pragmatic "this our usage cases, and we are not afraid to describe them in detail!" side of the street because, as I said, the academic discussions generally don't lead anywhere but in circles.   A pragmatic approach will, conversely, lead to doing just the basic minimums and not waste time implementing anything that won't actually be needed in real-world scenarios.

That ship already sailed off long ago (likely with Solaris 10 when
NFSv4 with Alternate Data Streams/O_XATTR was introduced) - its in use
now with a lot of applications.

Ced
-- 
Cedric Blancher <cedric.blancher at gmail.com>
Institute Pasteur