From nobody Wed Mar 26 14:43:36 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZN8gC2N4Qz5s2WT; Wed, 26 Mar 2025 14:43:51 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZN8gB2s2Hz432r; Wed, 26 Mar 2025 14:43:50 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=APbSPM5+; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::530 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5dccaaca646so1996656a12.0; Wed, 26 Mar 2025 07:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743000228; x=1743605028; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=9mY2qXC+hCoh9OzLaaoY+Ee4m4qMyehkuxjC4JFsLVY=; b=APbSPM5+EBg+FZP+I4CS25d02jxr8RdpL+WeLEii420dchsYCKCTIA6WEH8BphB4pU bmOJ68WMu+EeWL62NR5xMJr9dAkxqSLgeR5n1Rh2sl5QbwuNrwbKVFSFjOWsxM4TTcoY 0d4OQOMjfqtp4hBGDaZNqNatpY7I9meb3qnhtd8se/26C1m9P+nxsyVNgPk0QpFQjvF5 6x8eGlzmLaNDKfo7kGZOo5Khx+X1PXo+INmAv+ln4S00QbWMUaowqrLxhTy2cZPXMpCg m6Palktak6rOAL/m873plqYRhlili/Vwp4fsZqehrhj4XRr2KLu+Uzq4x0zB/MLk9FKL ylAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743000228; x=1743605028; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9mY2qXC+hCoh9OzLaaoY+Ee4m4qMyehkuxjC4JFsLVY=; b=kYlHfzZOh6LBz0gfhSQrTEWbsk/rRG+OzNiTu6+pEdaABWoR8H6xcN/Wnjw9ZqEglA 6lFBPjIqKc73P1pmSP3zgpz84NoI8D4DEPfJxcVcYwTu88iYPacEo3ZTifPNeIo3IQKI MmLw0CaK0y1xzozVfFTpsgePcZRClPAWeeiF780iWkBpa4UJune+JC/0R1d1/J/q7y95 SHk1IAeRb1irLd/E7iNQM+FeeD4MS1HSxzQmwKpl1l5irnOP5jtqeqtbArjAMjMs4inH VRNjkntv69opV7pq8o+YDvPsMQFvCyCpFTRpaGz1qpPpOFeJCd5T64Svu//e+lPw3Vad /MEg== X-Forwarded-Encrypted: i=1; AJvYcCUOg6aJUPxPwFVX0nKb+/k4pH/sEMvnp4BARyY0LvMts/SOTuU3WsP5tC5ts9a84GEVDtHK@freebsd.org, AJvYcCUklnD+HOSrt3mpSPdOzY6B0yibAT4329h0B2traZ0X2C2AZfN1Gb2VCeW6FJNnMPJs8T0E0Yqu4C/IZ9AaRUrS@freebsd.org, AJvYcCWTYfGnxwmesROVcYFv8A+AwBWtrm8g9ceyl07ADlqt0HD8lcC3e5aUUvPrdopDH4DZOnNyHIryhWUnUyw=@freebsd.org X-Gm-Message-State: AOJu0YyMbgRcVhFPTUISlAC9Pb2nDs8DXLNJBYBH2r3v73CZ+vCVWUoh L7U/haNqDoxNzOHggyNODp6Gtyi+/h+E9OcZ5HxxHg8alEBLAms/34RfOv1phanY6N5RkAdJ0T3 jtkDbJc82zHmNBVQSJ7hTpl4IiLbl X-Gm-Gg: ASbGnctNhYjKJ7iMfgnoWZD5d4CQqoWkDQXr/xOUMopgRlNiD5515fbu05ZRvSHm1mX 4jn6oRCSgJrxwn8imObKblbnl9NR/+hV2LI8Q8bVa9jrBW0dquGIvuAN0M2ebe+Y9O3py4mrWbq ARN8nIgUf3kWkWWj0+tBfMlTXwWMKxxG/ftuMQo9KwUbD6wvjyDxUbUZBgZw== X-Google-Smtp-Source: AGHT+IEmvs6YhUZ4Fu5xFl6ijj0xUJHn+8tpU8l49/g65qraETvyPzNn/QmkwXuDddEqo5h/7f3hRg+H1DUrDbgAuHQ= X-Received: by 2002:a50:9b0b:0:b0:5ed:53f7:a46c with SMTP id 4fb4d7f45d1cf-5ed53f7a592mr2455374a12.12.1743000227693; Wed, 26 Mar 2025 07:43:47 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Wed, 26 Mar 2025 07:43:36 -0700 X-Gm-Features: AQ5f1JpQ7_HjzLlsteq5st_W6_J_E-hYiMoHCnoP40UTFjaSVemJNhf8UwJBxFw Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Lionel Cons Cc: Andrew Walker , Konstantin Belousov , freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-2.48 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.99)[-0.995]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::530:from]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_FIVE(0.00)[6]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_CC(0.00)[ixsystems.com,freebsd.org,gmail.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-Rspamd-Queue-Id: 4ZN8gB2s2Hz432r X-Spamd-Bar: -- On Wed, Mar 26, 2025 at 2:39=E2=80=AFAM Lionel Cons wrote: > > On Tue, 25 Mar 2025 at 22:14, Rick Macklem wrote= : > > > > On Tue, Mar 25, 2025 at 1:53=E2=80=AFPM Rick Macklem wrote: > > > > > > On Tue, Mar 25, 2025 at 12:06=E2=80=AFPM Lionel Cons wrote: > > > > > > > > On Sat, 22 Mar 2025 at 21:34, Rick Macklem = wrote: > > > > > > > > > > On Sun, Mar 9, 2025 at 5:38=E2=80=AFAM Andrew Walker wrote: > > > > > > > > > > > > > Since ZFS is already wired for them, adding the basics is pre= tty > > > > > > > straightforward. I am not suggesting that they should replace= the > > > > > > > current FreeBSD extended attributes > > > > > > > > > > > > The ZFS story is more complicated. When ZFS is configured with > > > > > > `xattr=3Dsa`, xattrs are preferentially written into system att= ributes > > > > > > (SA). This was introduced IIRC primarily for performance reason= s > > > > > > This allows tiny xattrs (~100 bytes) to be stored with the dnod= e and > > > > > > up to 64 KiB of xattrs to be stored in the dnode spill block. I= f > > > > > > additional space is needed then they are written using the olde= r-style > > > > > > file-backed approach. > > > > > > > > > > > > What this means is that if someone is using this relatively com= mon > > > > > > configuration (the default in TrueNAS and in many Linux distros= ), then > > > > > > the result would be that only some xattrs written via extattr w= ould be > > > > > > visible by directly opening the ZFS attr dir. It would also int= roduce > > > > > > a mechanism whereby an xattr with the same name is written to t= wo > > > > > > different ZFS locations, which would potentially cause you to s= ee > > > > > > different xattr data depending on whether you read it from exta= ttr or > > > > > > via the attr dir. I don't know off-hand whether this could lead= to > > > > > > corruption / unexpected behavior in ZFS but if you haven't look= ed into > > > > > > it yet you may want to make sure you're properly handling the c= ase > > > > > > where someone has already written SA-backed xattrs. > > > > > I am in the process of defining a new setting for the xattr prope= rty > > > > > I've called "named" which would need to be set for the Solaris st= yle > > > > > extended attributes to work. > > > > > > > > > > I am making progress on the patch and am currently working throug= h > > > > > permissions (or authorization if you prefer). > > > > > > > > > > Here is what OpenZFS appears to do currently. > > > > > I am wondering if these sound reasonable for these attributes? > > > > > > > > > > - When an attr directory is created for a file object, the owners= hip > > > > > (uid and gid) is set to the same value as the file object. > > > > > The mode is set to 041777 (a directory with sticky bit set and > > > > > permissions for everyone. (It ignores the "mode" argument to > > > > > the open.) > > > > > --> As such, anyone who has access to the file object can acces= s > > > > > the extended attribute directory. > > > > > > > > Yes, that is the expected behaviour > > > > > > > > > > > > > > - When an attribute is created in the attribute directory, the ui= d is > > > > > set to that of the creating process (cr_uid), the gid is set t= o that > > > > > of the directory (which is also the gid of the file object). > > > > > The mode is set to that of a regular file with low order mode = bits > > > > > as specified by the "mode" argument to the openat() that crea= ted > > > > > it. > > > > > The mode can be changed with fchmod(2). > > > > > --> As such, access to each attribute file is controlled by the > > > > > attribute file's creator. > > > > > > > > > > Any comments on the above? > > > > > > > > Yes, that would be the expected behaviour. > > > > > > > > > > > > > > A couple of other questions... > > > > > - Should subdirectories of the attribute directory be supported? > > > > > I currently do not allow this, but it appears to be supportable > > > > > by both OpenZFS and NFSv4. > > > > > > > > No, please no subdirs for now. As far as I can see all consumes of > > > > such an API (Windows, MacOS etc) use flat layouts for the attribute > > > > and alternate data streams virtual dirs > > > > > > > > > > > > > > - Does restricting this support to ZFS file systems with the > > > > > xattr property set to "named" sound reasonable? > > > > > > > > What does that mean? > > > > Also, it should be "on" by default, both in FreeBSD ZFS, UFS and NF= S >=3D v4.1 > > > Hmm. I think (and the discussion with Andrew seemed to confirm it) > > > that they do not > > > mix well with FreeBSD/Linux style extended attributes. (For example, > > > the code that > > > checked access for the parent directory is disabled for FreeBSD style > > > attributes and > > > this is intentional, according to the comment.) > > > > > > Also, I doubt anyone will ever do support for UFS? (I am certainly no= t > > > volunteering.) > > > > > > The above means that a sysadmin will need to choose between which sty= le > > > of extended attributes they want on a "per file system basis" and tha= t FreeBSD > > > style will be the default, since to change that would be a POLA viola= tion, imho. > > > (If others feel that having the two styles co-exist on the same file > > > system is needed, > > > there might be a way to do it, but doing so properly won't be easy. > > > Another example > > > is naming. If both co-exist on the same file system, you can end up > > > with two different > > > attributes with the same name. I did this during testing, so I know i= t > > > can happen.) > > > > > > > > > > > > > > > > > Thanks for any comments, rick > > > > > ps: I have not, as yet, heard any comments w.r.t. whether or > > > > > not this should go into FreeBSD15. (No rush on this one, > > > > > but comments would be appreciated. > > > > > > > > I'd prefer the integration as soon as possible. > > > A couple of problems here. > > > 1 - You and Cedric are the only ones that have spoken up with support= for this. > > > (Having said that, no one has spoken up against it.) > > > 2 - Someone needs to do the "userspace" lifting at some point. > > > I haven't yet asked, so I do not know if you feel commands like = "chmod(1)" > > > need to be "named attribute aware"? (The fchmod(2) syscall works= , but > > > does the command line need to know how to do it? If yes, this is= work. > > > Probably more than I've spent getting the syscalls to work.) > > > 3 - A lot of the changes need to go into OpenZFS and I have no idea w= hat > > > their position will be? (Most of the changes are in the os/freeb= sd/zfs > > > source subtree, which may make it easier?) > > Oh, and another one... > > Testing. I have yet to hear from anyone trying to test the code. I obvi= ously > > do some testing, but my resources are limited. > > How can we do this? Grab patch, apply patch, build FreeBSD, install > new FreeBSD kernel? Yes. For now, only the kernel needs to be replaced. (I haven't yet quite figured out how to get the "zfs" command to set the new "named" value for the xattr property, so the patch always sets it (ok for testing only). Basically, install a recent FreeBSD snapshot of 15. If you go onto ftp.freebsd.org anonymous ftp, then cd into: pub/FreeBSD/snapshots/ISO-IMAGES/15.0 - You'll find a bunch of install images there. If you are installing on 64bit Intel (x86-64), you want one with "amd64" in the name. The ones I use have "disc1.iso" in the name. These are full install images that I burn onto a DVD. (I don't know what is convenient for newer hardware, but I'm sure someone will help if you can't figure out which one to use for the hardware/vm you are installing on.) Install it, including src. You'll need ZFS setup. This is covered in the handbook or you can just install a ZFS root fs for testing. Once this system is up, grab the patches and apply them to /usr/src. (If they don't apply cleanly, let me know and I can help. I am not tracking main/current and am using a Jan. snapshot.) Build/install a new kernel via (as root/su): # cd /usr/src # make buildkernel # make installkernel -> Reboot. # cp /usr/src/sys/sys/fcntl.h /usr/include/sys Now, you have to set up NFSv4. The basic steps are: - Create a /etc/exports. For testing one file system, 2 lines are needed. /filesystem -alldirs -maproot=3Droot V4: / (should be all you need for testing) Add the following lines to /etc/rc.conf: nfsuserd_enable=3D"YES" nfsuserd_flags=3D"-domain " nfs_server_enable=3D"YES" nfsv4_server_enable=3D"YES" nfsv4_server_only=3D"YES" - This should be sufficient for the NFSv4 server. To use the NFSv4 client, add: nfs_client_enable=3D"YES" nfscbd_enable=3D"YES" To do local testing of ZFS, you don't need the NFSv4 setup. Just cd into the ZFS file system and bash away at it. For both local testing and testing over NFSv4, you can start with https://people.freebsd.org/~rmacklem/xattrtest.c and work from there. > > The biggest issue for me is building and installing a new kernel in an > existing FreeBSD installation, or finding someone in-house who can do > that. > Howto or short blog post would be nice > > > > > For example, the pynfs test suite does have some xattr testing in it. > > However, I haven't used the pynfs test suite in a long time and am not > > a Python guy. It would be nice if someone else fired it up and did this > > testing. (If problems are found, I could probably track them down and > > fix them.) > > > > rick > > ps: In case you do not know, I am one guy who does this NFS stuff as > > a spare time hobby. I am not paid any $$$ by anyone to do it. > > Well, if you want a (NFS) job at CERN let me know (on-site, not remote). Thanks, but I am just shy of the big 70 and happily retired. rick > > Lionel