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.
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.
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.
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.
--
Alexander Motin
