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?)
- 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
