Date: Mon, 13 Jan 2025 08:34:00 +0100 From: Cedric Blancher <cedric.blancher@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: FreeBSD NFSv4.1 nfsd, named attribute support (OPENATTR)? Message-ID: <CALXu0Ue%2By-hzHWpo_nhUwpdAfxW9FUuUvPOisRRHkgW2TkqZ4A@mail.gmail.com> In-Reply-To: <CAM5tNy5HLEGZc=EMuD%2BQFhFRZg5SwmN6P5KvwMFPO5%2B3Cckh3g@mail.gmail.com> References: <CALXu0Ufwu_tsZW7mgLLGySbB_XMVOChwEyK1Z%2Br3rpYiXiyXGg@mail.gmail.com> <CAM5tNy5HLEGZc=EMuD%2BQFhFRZg5SwmN6P5KvwMFPO5%2B3Cckh3g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 12 Jan 2025 at 16:49, Rick Macklem <rick.macklem@gmail.com> wrote: > > On Sun, Jan 12, 2025 at 2:09=E2=80=AFAM Cedric Blancher > <cedric.blancher@gmail.com> wrote: > > > > Good morning! > > > > Does FreeBSD NFSv4.1 nfsd support named attributes (e.g. OPENATTR), > > per https://datatracker.ietf.org/doc/html/rfc5661#section-5.3 > > > > ZFS and Solaris UFS support named attributes (via O_XATTR), does > > FreeBSD do it too? > No. fork files/resource forks (or whatever you choose to call them) > have been discussed multiple times. > > If I recall correctly, one showstopper was fixing the archive tools. That is a no-issue. J=C3=B6rg Schilly (RIP) will rotate in his grave for that comment, at 50000rpm. Just RH keeps telling that story to avoid doing the work for Linux. I've heard so many excuses, all without a technical foundation, that I am sick of that kind of fairy tale. Just the cold hard fact in this case: Solaris already implemented archive tools support for O_XATTR/named attributes/Alternate Data Streams, even in a backwards compatible way. OPENATTR/Alternate Stream files in a USTAR/PAX archive are like regular file entries, but use "/dev/null" as file name, and have the attribute name in an extension header. Old tar/pax can safely unpack such archives (writing named attribute streams to /dev/null if they do not have code to handle it), and new tar/pax just unpacks them correctly. > There was also the generic argument that Linux doesn't support them. Since when does Linux dictate what *BSD should implement or not?? Also Linux tends to debate such topics literally to death, and nothing happens. For years. Throwing money at RH didn't work either. > Then there was the issue of what VFS/VOP changes were required. > (The FreeBSD VFS carries vnode locks across VOP calls and is at > what I would call a lower level than Solaris.) You don't need VOP, you only need kernel support for openat(). That is the beauty of O_XATTR, it neatly plugs into O_XATTR, and the kernel core code has little to do. > --> Which all comes down to who will do the work? > > If I recall correctly, there was a time when a group associated with > CERN needed them to transition away from Solaris. There are other groups who are interested in that. Mine for example, right with Alternate Streams support in the Windows NFSv4.2 (yes, 4.2!!) driver, because lots of commercial stuff in Bioinformatics uses ADS (https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/= e2b19412-a925-4360-b009-86e3b8a020c8) > > Anyhow, maybe the discussion will happen again here and now, rick Yes, please Ced --=20 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?CALXu0Ue%2By-hzHWpo_nhUwpdAfxW9FUuUvPOisRRHkgW2TkqZ4A>