Date: Tue, 26 Nov 2013 09:08:29 -0800 From: Jordan Hubbard <jordan.hubbard@gmail.com> To: Lionel Cons <lionelcons1972@gmail.com> Cc: Freebsd hackers list <freebsd-hackers@freebsd.org>, Richard Yao <ryao@gentoo.org>, Pedro Giffuni <pfg@freebsd.org>, Cedric Blancher <cedric.blancher@gmail.com>, Rick Macklem <rmacklem@uoguelph.ca> Subject: Re: Alternate Data Stream Support in FreeBSD (was Re: O_XATTR support in FreeBSD?) Message-ID: <1934C2F2-C380-4689-A811-61BB0009BA6B@gmail.com> In-Reply-To: <CAPJSo4XFNxZLPG=uvZkCdhOX08Wt_JqNCAOV-Eg58pw0U%2BsavQ@mail.gmail.com> References: <CAPJSo4XFNxZLPG=uvZkCdhOX08Wt_JqNCAOV-Eg58pw0U%2BsavQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 26, 2013, at 4:27 AM, Lionel Cons <lionelcons1972@gmail.com> = wrote: >> I don=92t know if I=92d go so far as to say =93you do not need more = syscalls=94; >> there are additional functions for manipulating EAs that go well = beyond >> the Solaris extensions to the directory and file I/O functions. = Assuming you >> want to be able to get/set as well as enumerate or remove EAs, then >> you might just as well add getxattr(2), listxattr(2), removexattr(2), = setxattr(2) >> too and follow the herd (Linux and OS X, so far). >=20 > You mean 'follow the lemmings down into the abyss'? :) Well, I don=92t know that it=92s an =93abyss=94 - EAs may or may not be = useful, depending on how you employ them! In the first version of OS X to support them, in fact, I believe they = were limited in size to 4883 bytes (don=92t ask me why that number) and = they were still used to apply various =93tags=94 to files (Finder = metadata, some index values into the search database, etc). General = pressure to use them for more things eventually got this size bumped up = to 128K, and now it=92s actually 2GB(!) = (http://support.apple.com/kb/HT5983) so I think it=92s fair to say that = EAs in OS X are now essentially equivalent to forked files, more or = less. > Could we first agree what we are talking about, please? I'm a bit new > to this thread, but AFAIK we are talking about the Windows Alternate > Data Streams as they appear in networked filesystem like NFSv4 and > CIFS and physical filesystems like NTFS, ZFS and Solaris UFS, right? > ACLs have no direct relation to those streams. Actually, I didn=92t think we were talking about alternate data streams = myself. Conceptually they=92re equivalent, I guess, but I=92ve always = through they were somewhat overkill and I=92ve yet to encounter an = application that seriously uses them. I=92m sure they=92re out there = somewhere, but even back in the days when EAs were limited to just over = 4K, we found them very useful for what was essentially their original = purpose - an extension to the file attribute data that Unix already = proves. The only reason that ACLs crept into the discussion is because = of where they=92re stored. I don=92t know about Linux, but Apple has = chosen to store ACLs in EAs, which is pretty useful because this gives = you an easy way of serializing the ACLs too - you just serialize them = from a suitably privileged process. The main point I was trying to make is that if you=92re going to have = EAs at all, you need to commit fully. The various Unix tools need to = support them (we=92ve already talked about the archivers and = compressors) and tools like ls(1) need to be able to show them on files. = You need a way of dealing with them on foreign filesystems that don=92t = support EAs. Most folks just cram EAs into the filesystem, add a few = decorations to existing system calls and then shout =93done!=94 and do a = victory dance. Then when nobody actually uses EAs, they go =93See? I = always told you EAs were crap! Terrible idea! Never should have added = them!=94 This is tantamount to building a car with an engine but no wheels, = dashboard or steering wheel and then declaring that the world just isn=92t= ready for cars since they=92re not buying yours. I know you cite Solaris=92 integration as an example of such a =93full = solution, and maybe the =93~@=93 syntax was awesome in practice, I = dunno, all I can say is that the only namespace trick we needed to pull = at Apple were the AppleDouble (._) sidecar files. There was an earlier = filename/..rfork/ syntax for addressing resource forks, which predated = EAs in OS X, and some folks used it quite a bit, but it was eventually = deprecated in favor of the single sidecar file. I never found a need to = =93cd=94 into the namespace of a file=92s EAs when I had the xattr(1) = command so handy for deleting / changing them, and ls=92s -@ argument = would also display them for me. I suppose it is all a matter of taste. = If someone wanted to do the namespace thing in FreeBSD, I wouldn=92t = argue against it. I also wouldn=92t argue against fully parallel =93forks=94 being a = superset of EAs, since I guess at CERN where folks are routinely looking = at Petabytes of data from a detector like ATLAS or CMS, anything that = puts size constraints on their data is just the devil, but again, that = wasn=92t actually the point I was trying to make. I was simply trying = to say that NFSv4 or ZFS =93native EA support=94 is the easy part. The = harder part is in making sure that the EAs don=92t get stripped out in = transit or during routine file manipulations, and this requires that = everything from cp(1) to rsync(8) becomes EA-aware. Most of the = implementations I=92ve seen don=92t bother to do that last mile of = integration, and as a result EAs are just basically untrustworthy beasts = that users shy away from. - Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1934C2F2-C380-4689-A811-61BB0009BA6B>