On Wed, Mar 26, 2025 at 1:16 PM Rick Macklem <rick.mack...@gmail.com> wrote: > > On Wed, Mar 26, 2025 at 11:36 AM Alexander Motin <m...@freebsd.org> wrote: > > > > Hi Rick, > > > > On 25.03.2025 16:53, Rick Macklem wrote: > > > 3 - A lot of the changes need to go into OpenZFS and I have no idea what > > > their position will be? (Most of the changes are in the > > > os/freebsd/zfs > > > source subtree, which may make it easier?) > > > > I haven't looked on the patches yet, and I may not speak for the whole > > OpenZFS project, but I'd put emphasis on a cross-OS compatibility of the > > implementation, including the properties, namespace prefixes for > > different APIs, etc. > > > > Since the directory-style attributes are growing from Solaris, it would > > be nice if whatever API and on-disk format chosen would be compatible > > with it. Even though the merge traffic with Illumos is not that big > > lately and they are formally not a part of OpenZFS, but would be nice to > > not break the ties if possible. It might require some code archeology > > to understand the evolution of compatibility issues we have now. > As far as on-disk, I have done nothing. The patches just use what is already > there. > > As for the API, I am not familiar with what solaris did, since that > seems to have been stripped out? (I can see from man pages that the > syscall interface uses O_XATTR, but I do not see any indication how > that might land in ZFS? I suppose I can dive into Illumos sources, > but I'll admit I am not excited by the prospect.;-) > > The big question I see is whether these attributes (or the API to get at > them, if you prefer) should co-exist with the Linux/FreeBSD style on the > same file system? > > If I understand the code (I may not), the Linux/FreeBSD style extended > attributes are layered on top of the Solaris style ones stored in ZFS. > There are some quirks that I haven't quite figured out yet. > - How does the Linux/FreeBSD style determine attrnamespace? > (I think it might be done via a "user." or "system." prefix, but I haven't > figured it out yet?) Ok, I just figured out a little more of this for the FreeBSD case... When zfs_xattr_compat is set (which is the case in the code now), the userspace attributes do not get any prefix.(This appears to be meant to be compatible with Solaris, but not Linux?) With zfs_xattr_compat zero, it prefixes "user.", which does appear to be Linux compatible? For system space, it puts "freebsd:system:" as a prefix. Definitely FreeBSD specific.
It seems that FreeBSD's naming can be Solaris compatible for user space, but I still do not know how I got a duplicate name? (The code already appears to know to ignore the system space ones that start with "freebsd:system:" for the attribute directory stuff.) rick > - For FreeBSD, the code (in zfs_zaccess()) just punts, then calls like > zfs_setextattr() which implement the VOP kapi use FreeBSD generic > functions like exattr_check_cred() to do the checking. > --> I ended up cribbing the code from the Linux side to do the checking > in zfs_zaccess() for the Solaris style attributes. > The problem is...zfs_zaccess() must decide whether or not to punt. > --> As such, I have currently coded it so that the two styles do no > co-exit on the same file system. > I have succeeded in creating two attributes that show up with the > same name (one created via zfs_setextattr() and the other via the > named attribute syscall. So, I need to keep working on this.;-) > > > > > FreeBSD and Linux are equally important targets in OpenZFS now, and > > while some things might be difficult to implement on all platforms, for > > example Linux kernel does not support NFSv4-style ACLs, whatever design > > chosen should allow such perspective, even if not implemented > > immediately. So I am a little worried about "Most of the changes are in > > the os/freebsd/zfs source subtree". We don't want it to get implemented > > differently in Linux one day and become impossible to move pools between > > OS'es. We already have issues there, so would be good to not grow them. > All I've seen w.r.t. the Linux side was a discussion (dated 2016) where they > discussed the possibility of using an ioctl() API for doing this. > As far as I know, nothing came of it. > > Most of the ZFS changes are FreeBSD specific, since they involve > the FreeBSD VOP_LOOKUP(), which is definitely FreeBSD specific. > (One weirdness is that ".." in these named attribute directories refers > to the file object the attributes are associated with. As such, ".." often > refers to a non-directory. This is what the ZFS code does and is > mentioned in the NFSv4 RFC, with a SHOULD. (In NFSv4, "..' doesn't > exist, but is accessed via the lookup parent operation.) > > > > > While formally not a part of OpenZFS tree (yet?), there are forks for > > Windows and MacOS. It would be cool to understand at least basic > > requirements of those systems. > My vague understanding is that both of these do something close to > Solaris style, although I can never remember their terminology. > A couple of the guys in this discussion might be able to help w.r.t. > Windows, since I think their interest is related to a Windows NFSv4.1 > client. Anyone able to comment? > > > > > Don't get me wrong. I'd be really happy to see it done at least from > > the perspective of its being implemented for Solaris decades ago, and > > considering limitations other systems including FreeBSD have. It just > > might be a bit tangled after the years. > The current patch > https://people.freebsd.org/~rmacklem/xattr.patch > isn't particularly large and is really just the API rigging > which basically seems to work. > It has a bunch of printf()s in it which make it a little hard to read > and does not yet try to make ZFS build for systems without the > rest of the patch. > > Maybe you would find it easy to take a look at? rick > > > > > -- > > Alexander Motin
