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

On Thu, Jul 10, 2025 at 06:59:35AM -0700, Rick Macklem wrote:
> 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.)

I do not see why not put it to named_attribute(7) page.  We do not have a
ban on adding important fs-specific notes in the generic documentation.
More, I think it is a proper place to document the details instead of
spreading them into corners.

BTW, would you consider adding named attrs support to tmpfs?
I believe it is useful for tmpfs to be on par with the union of
all features of our local filesystems.