Date: Tue, 3 Dec 2013 11:10:15 +0100 From: Cedric Blancher <cedric.blancher@gmail.com> To: Jordan Hubbard <jordan.hubbard@gmail.com> Cc: Rick Macklem <rmacklem@uoguelph.ca>, Freebsd hackers list <freebsd-hackers@freebsd.org>, Richard Yao <ryao@gentoo.org>, Pedro Giffuni <pfg@freebsd.org>, Lionel Cons <lionelcons1972@gmail.com> Subject: Re: Extended Attributes and how to avoid them (was Re: O_XATTR support in FreeBSD?) Message-ID: <CALXu0UdOP0Uag_crn-d0jWR5jjY9zyYR=o6H22WOeg5zhe8L-Q@mail.gmail.com> In-Reply-To: <92F46317-D62D-4E19-B687-2A392309A244@mail.turbofuzz.com> References: <BC41DB59-5868-432D-9452-00F420934E12@mail.turbofuzz.com> <718836647.19911209.1385302696963.JavaMail.root@uoguelph.ca> <CALXu0UfEQD2y6m5irGQRms=6bY8H854v0Wu9_96JpL4w6wntcg@mail.gmail.com> <706707CA-BD52-4814-BCCE-EB044B062BA6@kientzle.com> <CAPJSo4WvVpjUGkcOFcX19x%2BYBDp3eaf_j=UuoT7epoYmUCcWJQ@mail.gmail.com> <92F46317-D62D-4E19-B687-2A392309A244@mail.turbofuzz.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2 December 2013 00:19, Jordan Hubbard <jordan.hubbard@gmail.com> wrote: > > On Dec 1, 2013, at 2:05 PM, Lionel Cons <lionelcons1972@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, b= ecause 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'v= e worked with EAs "in the field", as it were, a lot (a LOT) and no one duri= ng my long history with them has ever demanded the ability to call read() o= r 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 technic= al 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 t= hat fashion were truly necessary, I suspect I would have heard that early a= nd 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 enoug= h" 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!" si= de of the street because, as I said, the academic discussions generally don= 't lead anywhere but in circles. A pragmatic approach will, conversely, l= ead to doing just the basic minimums and not waste time implementing anythi= ng 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 --=20 Cedric Blancher <cedric.blancher@gmail.com> Institute Pasteur
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CALXu0UdOP0Uag_crn-d0jWR5jjY9zyYR=o6H22WOeg5zhe8L-Q>