RFC: Documenting weird case w.r.t. Solaris style extended attr (ZFS)

From: Rick Macklem <rick.macklem_at_gmail.com>
Date: Thu, 10 Jul 2025 13:59:35 UTC
I've done a series of commits to main to add support for
Solaris style extended attributes (which I called named attributes,
which is the NFSv4 term for them).

ZFS is currently the only local file system that will support them
and only if the ZFS property "xattr" is set to "dir".

If "zfs set xattr=dir <volume>" is done before any user namespace
extended attributes are created for files via extattr(2), I think
everything makes sense.
--> There is one set of extended attributes that are visible through
      both extattr(2) and named_attribute(7).

However, if extattr(2) is used to create user namespace extended
attributes when "xattr=sa" and then "xattr" is set to "dir", these
extended attributes are only visible to extattr(2) and not
named_attribute(7).
--> I will note that you can use tar(1) to copy the files and then the
     extended attributes become visible to named_attribute(7).
I do not see any way to avoid this, but it should at least be documented.

So, where do you think I should document this?
- I could put it in named_attribute(7) as an additional case where
  the two extended attribute system call mechanisms cannot be
  used. (I was hesitant, since this is ZFS specific).
Does this sound ok, or is there somewhere better to put it?
(zfsprops(7) is another possibility, since it already documents
"sa" and "dir" values for the "xattr" property.)

Thanks in advance for any comments, rick