Date: Sun, 24 Nov 2013 09:18:16 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Jordan Hubbard <jkh@mail.turbofuzz.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> Subject: Re: O_XATTR support in FreeBSD? Message-ID: <718836647.19911209.1385302696963.JavaMail.root@uoguelph.ca> In-Reply-To: <BC41DB59-5868-432D-9452-00F420934E12@mail.turbofuzz.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan Hubbard wrote: >=20 > On Nov 23, 2013, at 2:53 PM, Rick Macklem <rmacklem@uoguelph.ca> > wrote: >=20 > > 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?) Oops, my mistake. Robert has clarified what the VOP_OPENEXTATTR() is used for. Therefore, there doesn't appear to be any support for subfiles/fork files in the VFS (VOP_xxx()) or syscalls. > > 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. >=20 > Sigh. Extended Attributes. :-/ >=20 > I guess I=E2=80=99ll raise my head in this discussion. They=E2=80=99ve c= ertainly > been the bane of my existence for long enough! >=20 > First, supporting EAs properly really involves multiple levels of the > Unix command and library stack. >=20 > The filesystem can support them natively, sure, but that=E2=80=99s actual= ly > somewhat optional since you can always (cough cough) stick them in a > side-store if the rest of the stack cooperates. That=E2=80=99s where the > awesome AppleDouble files came from (=E2=80=9C._weirdfile" corresponding = to > =E2=80=9Cweirdfile") which remain useful even after filesystems like > HFS/ZFS/UFS became EA-aware natively because there=E2=80=99s 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=E2=80=99s been stored in an EA, if it gets stripped off the firs= t > time you tar up a directory and extract it somewhere else? >=20 > So I wouldn=E2=80=99t start with NFSv4 or ZFS if I was asking the questio= n. > 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! :) >=20 Righto, w.r.t. the client side. For the NFSv4 server side, it would be what the VFS and file systems support. Just to clarify, I wasn't interested in doing this. It was Cedric who asked about them. My impression is that with the Linux "marketshare", apps will tend to use the atomic limited size ones already supported by FreeBSD. (NFSv4.0 and 4.1 don't support these, but there is discussion w.r.t. adding support for them in a future minor revision of the protocol, possibly 4.2. The named attributes in NFSv4 expect the subfile/forkfile model and do not support atomic writing of an entire extended attribute.) rick > - Jordan >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?718836647.19911209.1385302696963.JavaMail.root>