First off, I cross posted because I don't think many read freebsd-arch@. There seems to be a nice market for Solaris style extended attributes. Since ZFS is already wired for them, adding the basics is pretty straightforward. I am not suggesting that they should replace the current FreeBSD extended attributes.
For those not familiar with them (I am not very familiar myself;-), a Solaris style extended attribute is in a directory that hangs off the file object and the entries in the directory (the attributes) can be manipulated with open/read/write/lseek just like a regular file. (They can be as large as a regular file, but there is no atomicity guarantees.) At this point I have a couple of rough patches: https://people.freebsd.org/~rmacklem/xattr.patch - the VFS/ZFS part https://people.freebsd.org/~rmacklem/nfs-xattr.patch - the NFSv4 part I have a simple test program to test the above: https://people.freebsd.org/~rmacklem/xattrtest.c The VFS/ZFS patch defines: O_NAMEDATTR - similar to O_XATTR, but uses the NFSv4 named attribute terminology to avoid confusion with the other style of FreeBSD extended attributes. (The semantics probably are not exactly the same either. I do not have a Solaris system to test on, so I am going from the NFSv4 and Solaris doc. I have handy.) --> You can look at xattrtest.c to see how this is used. I have not done any userland patches and am not sure what might be needed? (I suspect a variant of pax/tar that knows about these is the minimum?) I defined a couple of new v_irflag bits to indicate that a vnode is a named attribute directory or a named attribute. That way, they are still of v_type VDIR or VREG and can be handled by most of the code without change. So, now for the questions... 1 - Do you think this should be put in FreeBSD? (If the consensus is no, I will try and maintain out of tree patches.) 2 - If the answer for #1 is yes, what do you think is needed beyond what I already have (which is a way to open the named attribute directory and named attributes within that directory). Thanks in advance for any comments, rick
