Date: Sat, 26 Apr 2025 08:14:00 -0700 From: Rick Macklem <rick.macklem@gmail.com> To: Cedric Blancher <cedric.blancher@gmail.com> Cc: freebsd-arch@freebsd.org, FreeBSD CURRENT <freebsd-current@freebsd.org>, Lionel Cons <lionelcons1972@gmail.com> Subject: Re: RFC: Solaris style extended attributes for FreeBSD Message-ID: <CAM5tNy7QsM9t8xqrvyw1HicKrc1wpkyxTgfLBoVnP%2B1x99jn7g@mail.gmail.com> In-Reply-To: <CALXu0Ud3zmq_19BqcZpTOhOzLCcoG5ix3eq8pxU1r_xUgA-s3Q@mail.gmail.com> References: <CAM5tNy6wkfPRUpkyHB3h6=fhJHf-eFSWWNdeHV5VLA_xG7pGDA@mail.gmail.com> <CALXu0Ud3zmq_19BqcZpTOhOzLCcoG5ix3eq8pxU1r_xUgA-s3Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 22, 2025 at 3:34=E2=80=AFAM Cedric Blancher <cedric.blancher@gmail.com> wrote: > > On Sun, 9 Mar 2025 at 00:02, Rick Macklem <rick.macklem@gmail.com> 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 =3D 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? Thanks for any input, rick > > Ced > -- > Cedric Blancher <cedric.blancher@gmail.com> > [https://plus.google.com/u/0/+CedricBlancher/] > Institute Pasteur
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy7QsM9t8xqrvyw1HicKrc1wpkyxTgfLBoVnP%2B1x99jn7g>