Date: Sat, 23 Nov 2013 15:41:37 -0800 From: Jordan Hubbard <jkh@mail.turbofuzz.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: Freebsd hackers list <freebsd-hackers@freebsd.org>, Richard Yao <ryao@gentoo.org>, Pedro Giffuni <pfg@FreeBSD.org>, Cedric Blancher <cedric.blancher@gmail.com> Subject: Re: O_XATTR support in FreeBSD? Message-ID: <BC41DB59-5868-432D-9452-00F420934E12@mail.turbofuzz.com> In-Reply-To: <820263347.19772534.1385247218007.JavaMail.root@uoguelph.ca> References: <820263347.19772534.1385247218007.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 23, 2013, at 2:53 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote: > Interestingly, FreeBSD has a VOP_OPENEXTATTR() but no syscall > that uses it nor support for it in ZFS. (I'm just guessing it > was intended for an openat(2) syscall at some time?) > Btw Cedric, if you had mentioned "subfiles" or "fork files" in your > subject line, you might have gotten a better answer. I, for one, > didn't know what O_XATTR is. I also always get confused w.r.t. what > to call these beasts. (NFSv4 calls the named attributes.) >=20 > Btw, apps can use extended attributes (the limited sized > atomically stored/read kind). They aren't just for > storing ACLs. Sigh. Extended Attributes. :-/ I guess I=92ll raise my head in this discussion. They=92ve certainly = been the bane of my existence for long enough! First, supporting EAs properly really involves multiple levels of the = Unix command and library stack. The filesystem can support them natively, sure, but that=92s actually = somewhat optional since you can always (cough cough) stick them in a = side-store if the rest of the stack cooperates. That=92s where the = awesome AppleDouble files came from (=93._weirdfile" corresponding to = =93weirdfile") which remain useful even after filesystems like = HFS/ZFS/UFS became EA-aware natively because there=92s always those = foreign data stores to talk to (some early AFP/CIFS/NFS mount, for = example) and the fact that you still need to *serialize* the dang things = into tar / cpio / zip / ??? files as well as across network replication = with tools like rsync. What good is an EA, much less an ACL that=92s = been stored in an EA, if it gets stripped off the first time you tar up = a directory and extract it somewhere else? So I wouldn=92t start with NFSv4 or ZFS if I was asking the question. I = would start with libc and ask if it had anything similar to copyfile(3) = so that the tools above it could start actually supporting those = attributes on a *practical* basis! :) - Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BC41DB59-5868-432D-9452-00F420934E12>