On Sat, Mar 08, 2025 at 03:02:14PM -0800, Rick Macklem wrote: > 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). How to remove the attribute? Is there a way to rename?
Could you please (try) to explain the semantic, for instance, to add the same support for UFS? Might be tmpfs would be much easier as the target, if some non-trivial on-disk structures needs to be added to UFS, esp. due to SU.
