Re: RFC: Solaris style extended attributes for FreeBSD

On Mon, Apr 28, 2025 at 3:08 AM Lionel Cons <[email protected]> wrote:
>
> On Sat, 26 Apr 2025 at 17:14, Rick Macklem <[email protected]> wrote:
> >
> > On Tue, Apr 22, 2025 at 3:34 AM Cedric Blancher
> > <[email protected]> wrote:
> > >
> > > On Sun, 9 Mar 2025 at 00:02, Rick Macklem <[email protected]> wrote:
> > > >
> > > > First off, I cross posted because I don't think many read freebsd-arch@.
> > > > There seems to be a nice market for Solaris style extended attributes.
> > > > Since ZFS is already wired for them, adding the basics is pretty
> > > > straightforward. I am not suggesting that they should replace the
> > > > current FreeBSD extended attributes.
> > > >
> > > > For those not familiar with them (I am not very familiar myself;-),
> > > > a Solaris style extended attribute is in a directory that hangs off
> > > > the file object and the entries in the directory (the attributes) can
> > > > be manipulated with open/read/write/lseek just like a regular file.
> > > > (They can be as large as a regular file, but there is no atomicity
> > > > guarantees.)
> > > >
> > > > At this point I have a couple of rough patches:
> > > > https://people.freebsd.org/~rmacklem/xattr.patch - the VFS/ZFS part
> > > > https://people.freebsd.org/~rmacklem/nfs-xattr.patch - the NFSv4 part
> > >
> > > Any timeframe when
> > > https://people.freebsd.org/~rmacklem/nfs-xattr.patch will land in
> > > FreeBSD?
> > Should be in main in a week or so. I have already done one patch
> > commit, but there are a few more needed.
> >
> > On the bigger picture...
> > I have finally gotten Solaris going in a VM so that I could test stuff
> > on it and have found a couple of incompatibilities:
> > - I required O_CREAT for
> >    nameddir_fd = openat(file_fd, ".", O_NAMEDATTR, 0);
> >    to create the named attribute if it did not already exist.
> >    Solaris does not require O_CREAT for this case (when used
> >    with O_XATTR) and actually returns EINVAL.
> >    Solaris just creates the directory if it does not already exist.
> >
> >    Changing this is a trivial 2 line patch and I think being Solaris
> >    compatible makes sense. I required the O_CREAT, since I
> >    was thinking the syscall without it could be used to test to see
> >    if the named attribute directory exists, but I am not sure if that
> >    is useful?
> >
> > Do others think I should change the behavior to be Solaris compatible?
> >
> > - Solaris allows hard links to be created to a named attribute.
> >   I did not allow this, since I was concerned that having links to the
> >   same attribute for multiple file objects might be confusing.
> >
> > Do others think I should allow them?
>
> We've been debating this in a staff meeting today: From an API point
> of view Windows EA index and Streams (Alternate Data Streams) index is
> ALWAYS there, no special creation for the index required. MacOS
> Alternate Data Stream does the same, no need to create the index, it
> is always there.
>
> So we think Solaris is right.
Another Solaris compatibility question has come up.
Solaris uses a pathconf name _PC_XATTR_EXISTS that indicates
whether or not a file has named attribute(s) on it.
(This is separate from _PC_XATTR_ENABLED, which indicates if
the file system has named attribute support.)

I have coded this, but having a pathconf name for something that is
specific to a file is a bit weird. kib@ has suggested that it might be
better to do it as an ioctl().

So, do you think a pathconf variable is preferred, since it is
"Solaris compatible" or an ioctl()?

Also, I named it _PC_HAS_NAMEDATTR, but would you
prefer _PC_NAMEDATTR_EXISTS for the name, if pathconf()
is your preferred approach?

Thanks for any input, rick

>
> Lionel