Date: Sun, 4 May 2025 08:30:11 -0700 From: Rick Macklem <rick.macklem@gmail.com> To: Lionel Cons <lionelcons1972@gmail.com> Cc: Cedric Blancher <cedric.blancher@gmail.com>, freebsd-arch@freebsd.org, FreeBSD CURRENT <freebsd-current@freebsd.org> Subject: Re: RFC: Solaris style extended attributes for FreeBSD Message-ID: <CAM5tNy7gati2fmVrnnnqvyy6B6p5AzVbsThWn8AOXbUkkiLedA@mail.gmail.com> In-Reply-To: <CAPJSo4Xu4aCtOh5krcM%2Brw3yNj1vsMSaHPQQ-HQ=2QC-jjScng@mail.gmail.com> References: <CAM5tNy6wkfPRUpkyHB3h6=fhJHf-eFSWWNdeHV5VLA_xG7pGDA@mail.gmail.com> <CALXu0Ud3zmq_19BqcZpTOhOzLCcoG5ix3eq8pxU1r_xUgA-s3Q@mail.gmail.com> <CAM5tNy7QsM9t8xqrvyw1HicKrc1wpkyxTgfLBoVnP%2B1x99jn7g@mail.gmail.com> <CAPJSo4Xu4aCtOh5krcM%2Brw3yNj1vsMSaHPQQ-HQ=2QC-jjScng@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
On Mon, Apr 28, 2025 at 3:08 AM Lionel Cons <lionelcons1972@gmail.com> wrote: > > On Sat, 26 Apr 2025 at 17:14, Rick Macklem <rick.macklem@gmail.com> wrote: > > > > On Tue, Apr 22, 2025 at 3:34 AM 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 = 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 > > Lionelhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM5tNy7gati2fmVrnnnqvyy6B6p5AzVbsThWn8AOXbUkkiLedA>