From nobody Thu Mar 27 21:08:19 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 4ZNx8d4grLz5rvPw; Thu, 27 Mar 2025 21:08:33 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 4ZNx8c4Y5fz3wVT; Thu, 27 Mar 2025 21:08:32 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=TJIAQVON; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5ed43460d6bso2467676a12.0; Thu, 27 Mar 2025 14:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743109710; x=1743714510; 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=UranmtfHjBu5Ieon3zgi//rINf6snOuCaPIsZRl3jr4=; b=TJIAQVONMY4GQ1Xk1vdaU2OmeYpxxKXro9dWzfVonqxY84wzWRzs9NGBj91SAnzVgU vG5f3FSvLItvHjepEkN0rOwrpqXbq9c61Jbvkd4vAiqkP8clLXxeck7hXZKCzpocX0fD SlXWDOTJdQPopcf2uw1+W/YgA67Jbse+wjccC1JXXnUuBl9NPr8Edr+A4NCmusWjfYZ+ +4b+U3FpJ1Dz/sigMY+MH7gjlgtESgG+d0udL8y+eJIbOnIZ0Yax4cFCMkQhD+Mb8jUQ k9eqJ/WHEWojca+QxaIrdJT+JJ9ZGS6Zk8oq9DQQkFA7rytmzZ1RAQmpABGuhqKy0i1Y JLEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743109710; x=1743714510; 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=UranmtfHjBu5Ieon3zgi//rINf6snOuCaPIsZRl3jr4=; b=kTW2xJFxaAq8pE1kpEifQy44RRMN78UjSCeEuZ/cbwgUTNmUL+qmsZeDUEe0W2FyAk VumIrFpkwbjM6ruFhp8klWRSQ3mw8/2wVzWtaH0rGFjOmG8KTmQG7kxboZquERn8H/bI 0V/ww/CXKVA27OpJPm5208gD8V0v/eACc9DhX5Z1Xo9AVUiD3aEqq4AZlhI5J+bXCQ9/ tNE0D2hyJDloS5C73R+lSW7cIME3Bw+7FPIOC+cbRT9bUSsfjR4c8RThgu8p2t9UuB2c 2zdDjpjCQaUDSAZH4M9otSFGodwld9EP1QAXjcU3vLE6IZzrfqxi5cZi04sJ4cJ/NOTY CKig== X-Forwarded-Encrypted: i=1; AJvYcCU1VLZBm83Qvt9IQoCoIxiyNs+6ix0y/YfklI6kkSt6bMlZzsN27ZFB46coqTAg6IfeL5uQPhNXjHkujvyze7YV@freebsd.org, AJvYcCVRRS0xLna0BPo9o1qP6RZYyTKKCNWUNwJIKOAv6/ExpqJ8uzf7DLgZYUelYohi0ClHofTjax6lj38rMj4=@freebsd.org, AJvYcCW6v2jOnsNUrtbiGI5IBPnB+qt9J4tZkMsc7LBGdnjY0Mkd9rvScA5WUh2bIGzR9kFyZzeL@freebsd.org X-Gm-Message-State: AOJu0YzPAcE1QtxFgxOEroNQLeqZth2ediFMxCiT9b9PK7uY8WXfMaE4 9lplj8M52/X4syrk2irjxUaa/U3sv7x4JDyOb2Uq39wymT19SqQ95yADmGYLvTne6KJYDZIXinN m2XDyir8i/emcNSuS4EzCBezXMA== X-Gm-Gg: ASbGnctWJ2tMlFbRKP1MASbp/lRpQzDMj6+QuDqWX6JfaICx77uH3vPU8tjVTI5UNXl A/bxVpyBoe2W/cAt/EoLTBG3cUkJhXnsJGBg+Utgb4irJoyogJSHfVwggpHj3rivU/jxq4snhf+ Mwnd34ypskgVNPAVZrz6VEvj1OxBP8q6lI2F2HWbWD+mMj7JUusY1akn8zUw== X-Google-Smtp-Source: AGHT+IFSn7qlLRNDjOYx5jEZ+2fs9oXhlmKiCFGb0+YZOzs4QllcIQOKfsxHtchYwlNykZ3UQjHnNhf9VXzXucU4Eo4= X-Received: by 2002:a05:6402:1d4a:b0:5ec:c976:268a with SMTP id 4fb4d7f45d1cf-5ed8e4a9544mr5465356a12.15.1743109709961; Thu, 27 Mar 2025 14:08:29 -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: Thu, 27 Mar 2025 14:08:19 -0700 X-Gm-Features: AQ5f1JqoK57YHh8tQnLRuGCaNJ9wazKBEBdfIjRX6VqcUkd6gktSjUi2uHnXM4o 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_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.98)[-0.977]; 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::52a: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: 4ZNx8c4Y5fz3wVT X-Spamd-Bar: -- On Thu, Mar 27, 2025 at 11:23=E2=80=AFAM Lionel Cons wrote: > > On Thu, 27 Mar 2025 at 03:28, Rick Macklem wrote= : > > > > On Wed, Mar 26, 2025 at 5:36=E2=80=AFPM Andrew Walker wrote: > > > > > > On Wed, Mar 26, 2025 at 5:05=E2=80=AFPM Rick Macklem wrote: > > > > I am now less convinced that a new value for xattr is needed. > > > > I need to do more testing, but with xattr set to dir and not sa > > > > (shown as "on" for zfs get xattr), the attributes seem compatible > > > > and it is just the KAPI which changes. > > > > > > > > rick > > > > > > Rick, is it OK to serve the same information as an xattr and as a > > > named attribute over NFS? > > Good question. I don't have the answer. It seems that it "will work", > > so so long as the "system attrnamespace" attributes cannot be accessed/= created > > on the named attribute side, I don't se an obvious problem (see below). > > No, this is not intended to work that way. > > SUN plans with CITI's Windows driver was to implement Windows EA > (Extended Attributes) as "named attributes" (ref: > https://datatracker.ietf.org/doc/html/rfc5661#section-5.3) with a > prefix, e.g. EA attribute "abc" will have the ZFS/UFS/NFSv4 named > attribute named "windows.ea.abc". > Windows streams would also be prefixed, e.g. Windows stream "mystream" > would go into the name attribute "windows.stream.mystream". Well, right now ZFS has a function called zfs_check_attrname() to check for imbedded '/' characters and prefixes not allowed. The current list of prefixes is: "freebsd:" - Used by FreeBSD for system attrnamespace attributes "security." - Linux related, I think? "system." - Linux related? "trusted." - Linux related? "user." - Linux related? So, except for the last one, the restricted prefixes are ones that are used by the associated system for privileged attributes. (The last one "user." is a Linux-ism that can optionally be prefixed to all names, but that seems to be disabled by default.) Note that RFC8276 specifies "user" attributes, so the above mostly applies to attributes set locally in ZFS by Linux or FreeBSD. Note also that the prefixes you are suggesting would currently be allowed. > > Prefixing is important to avoid namespace collisions. For example > Solaris has the "SUNWattr_" prefix for their internal stuff. IANA > created a registry called the "NFSv4 Named Attribute Definitions > Registry" to register these prefixes. Since only Solaris has implemented named attributes as far as I know, I suspect this IANA registry is largely forgotten. RFC5661 notes that there is no initial registry. I just looked and there does not appear to be any prefixes registered. > > Finally, Linux xattr and Windows EA are size-limited, Windows streams > and NFSv4 named attributes have unlimited size, and can even be sparse > (Google SEEK_HOLE about that). > > So if someone wants to implement Linux XATTR, then do it as SUN > intended, and create a "linux.xattr." prefix. Well, as I noted above, that is not what the Linux ZFS port does and I am not going to try and tell them it needs to change.;-) > > Lionel