On Sun, Mar 9, 2025 at 1:34 AM Konstantin Belousov <k...@freebsd.org> wrote: > > CAUTION: This email originated from outside of the University of Guelph. Do > not click links or open attachments unless you recognize the sender and know > the content is safe. If in doubt, forward suspicious emails to > ith...@uoguelph.ca. > > > 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? unlinkat(2) and renameat(2). If you look at the version of https://people.freebsd.org/~rmacklem/xattrtest.c you'll see them tested.
What I still working on is restrictions for other syscalls, which shouldn't work on them. (I currently don't think mkdir/rmdir/mknod/symlink should work.) I also need to look at how/what checking ZFS does w.r.t. their access permissions. (I currently think access is defined by the parent file object?) > > 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. Not sure there is any point in doing other file systems. Anyone who wants these can use ZFS. (After all, only UFS and ZFS support NFSv4 style ACLs, so we already have features that only some file systems support.) As far as semantics, the attributes are basically a directory with regular files in it, but referred to by the parent file object instead of a name in the file system's name space. (ZFS does generate "." and ".." in the directory, but I haven't yet looked to see what those refer to?) rick > >
