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 -- -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
