O_XATTR support in FreeBSD?

[Rick Macklem]

Jordan Hubbard wrote:
> 
> On Nov 23, 2013, at 2:53 PM, Rick Macklem <rmacklem at 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?)
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.)
> > 
> > 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’ll raise my head in this discussion.  They’ve 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’s actually
> somewhat optional since you can always (cough cough) stick them in a
> side-store if the rest of the stack cooperates.  That’s where the
> awesome AppleDouble files came from (“._weirdfile" corresponding to
> “weirdfile") which remain useful even after filesystems like
> HFS/ZFS/UFS became EA-aware natively because there’s 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’s 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’t 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! :)
> 
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
> 
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscribe at freebsd.org"
>