Date: Tue, 26 Nov 2013 10:51:55 +0100 From: Cedric Blancher <cedric.blancher@gmail.com> To: Freebsd hackers list <freebsd-hackers@freebsd.org> Cc: Rick Macklem <rmacklem@uoguelph.ca>, Richard Yao <ryao@gentoo.org>, Pedro Giffuni <pfg@freebsd.org>, Jordan Hubbard <jkh@mail.turbofuzz.com> Subject: Re: O_XATTR support in FreeBSD? Message-ID: <CALXu0UfEQD2y6m5irGQRms=6bY8H854v0Wu9_96JpL4w6wntcg@mail.gmail.com> In-Reply-To: <718836647.19911209.1385302696963.JavaMail.root@uoguelph.ca> References: <BC41DB59-5868-432D-9452-00F420934E12@mail.turbofuzz.com> <718836647.19911209.1385302696963.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24 November 2013 15:18, Rick Macklem <rmacklem@uoguelph.ca> wrote: > Jordan Hubbard wrote: >> >> 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?) > 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=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! :) >> > 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.) Some clarifications: 1. You do not need more syscalls. Solaris uses the plain openat() syscall for this, with the O_XATTR flag passed to the normal open()/openat() flags to open a named attribute. Likewise read(), write(), mmap() etc work, too. 2. The filesystem implementation should be quite easy too. For example Solaris UFS seems to use the special *file* name '/@/' (or part of a file name, I don't know) to describe that this is a named attribute 3. We use NFSv4 attributes (as opened with O_XATTR, accessed with openat(), read(), write() like normal files, and most importantly with unlimited size) quite expensively, and if you look around you see that institutions like CERN, software like SAMBA or SAP+OracleDB or much code from NIH uses this stuff. 4. Usage seems even to be common enough that the latest ksh version (ksh93v-) includes special support for O_XATTR attributes (like cd -@ filename or a builtin virtual filesystem (like ksh's /dev/tcp/host/portnumber) so that you can use cat </dev/file/xattr... to access such files) using either the openat(...,O_XATTR) API or the Windows Alternate Streams API (on UWIN) 5. Support for tar and pax is already there. Its described in Solaris's fsattr man page, they use a extended header with filename /dev/null (to prevent older tar versions from tripping over the new headers) and then have a named attribute header which describes the attributes names and flags. 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?CALXu0UfEQD2y6m5irGQRms=6bY8H854v0Wu9_96JpL4w6wntcg>