This is a clean start to discuss extended attributes over NFS in the
mailing list first.
1. What are the requirements and why? which applications are using them
and how.
2. Why are current named attributes in NFS not the right answer.
3. What does the new protocol enhancements should look like?
Marc.
On Mon, Oct 28, 2013 at 03:28:42PM -0700, Marc Eshel wrote:
> This is a clean start to discuss extended attributes over NFS in the
> mailing list first.
>
> 1. What are the requirements and why? which applications are using them
> and how.
Surely the requirements would be semantic compatibility with Linux's
xattrs. These are defined in manpages such as getxattr(2). Links can
be easily found online.
: ; man -s2 -k xattr
fgetxattr (2) - retrieve an extended attribute value
flistxattr (2) - list extended attribute names
fremovexattr (2) - remove an extended attribute
fsetxattr (2) - set an extended attribute value
getxattr (2) - retrieve an extended attribute value
lgetxattr (2) - retrieve an extended attribute value
listxattr (2) - list extended attribute names
llistxattr (2) - list extended attribute names
lremovexattr (2) - remove an extended attribute
lsetxattr (2) - set an extended attribute value
removexattr (2) - remove an extended attribute
setxattr (2) - set an extended attribute value
: ;
Whether there are apps that use them is a different story. I've no
idea, but here's a github search for code using getxattr:
https://github.com/search?q=getxattr&ref=cmdform&type=Code
Many of the results are from clones of Android, so one has to wade a
fair bit to find apps. Things like this:
https://github.com/protonet/xattr
https://github.com/jarib/ffi-xattr
make it harder to tell what's using them.
Then we have:
https://github.com/search?q=getxattr&ref=cmdform&type=Issues
which is a bit better, since this brings up more issues with apps using
xattrs and fewer about implementations of xattrs, like:
https://github.com/Cocoanetics/DTFoundation/issues/37
Even then, most of the issues (only 5 pages) relate to filesystems and
FUSE.
Interesting data point: both, an OS X port of ZFS, and ZFSOnLinux felt
the need to add support for xattrs.
The only apps I found this way are the above DTFoundation, Ruby FFI
bindings of xattrs, and:
https://github.com/tobiaswaldvogel/openwrt-addpack
https://github.com/mxcl/homebrew
https://github.com/scrod/nv
https://github.com/ShareKit/ShareKit
> 2. Why are current named attributes in NFS not the right answer.
They have different semantics and namespaces.
xattrs are small, bite-sized.
Named attributes as files within files -"forks"- and align well with
openat(2) but not with *xattr(2).
> 3. What does the new protocol enhancements should look like?
Probably like direct equivalents of the xattrs system calls as OPs
operating on the current FH. This seems like the simplest question to
answer.
I'm not advocating adding xattrs to the protocol. I'm not sure there's
a real case for this. Developers ought to be using openat(2) more and
xattrs less. Forks interop better with, e.g., Win32, than xattrs.
Perhaps xattrs could be implemented as a conventional mapping onto named
attributes. This would require agreement by many people, including
implementors of filesystems that already have both features, so it seems
unlikely, except, perhaps, via reserving named attribute namespace for
implementation purposes, but even that I think is (IIRC) not allowable
for NFSv4 (i.e., the named attribute namespace is already wide open for
use by the public).
This really brings up a different matter: to the extent that xattrs and
named attributes are used to store application data (as opposed to
arbitrary user-named attributes) perhaps we ought to have a registry for
naming them.
Nico
--
This is a clean start to discuss extended attributes over NFS in the
mailing list first.
1. What are the requirements and why? which applications are using them
and how.
2. Why are current named attributes in NFS not the right answer.
3. What does the new protocol enhancements should look like?
Thanks, Marc.