From nobody Wed Mar 26 20:45:15 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 4ZNJhV5FWFz5r9bl; Wed, 26 Mar 2025 20:45:30 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 4ZNJhT53Hzz3L5N; Wed, 26 Mar 2025 20:45:29 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=DpvheaEE; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of rick.macklem@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=rick.macklem@gmail.com Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5e5e0caa151so463838a12.0; Wed, 26 Mar 2025 13:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743021927; x=1743626727; 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=sr3YFov4BK2aTNvFd813PJ6MLOn0vE3kzg2fcZoBPhI=; b=DpvheaEEcEgMG/vRT7M8F8Z2rNu2Uq3inel1Ag2huC/qPE9/Q1vuEqrhdn8lSDAv0a bYmq5zErdJBdB0xBDLzMB8MbHXQ5lWmCyRpIsRA828ZOoqgbZt16GRxs3yCgTCA//Z/P jcGDFYRxIpksaAorYsmXLqmZ/F8lNhEfeFOdffIialfd/0+Oom99X15HPDCXofn/fOGg eeBHK5jElTlhwHSG/B58b+OUF7iSgOLaYuWA1qp+XGAgoSBPLSKHDuTmqvBbxC96ir3F sTehhR5zCMLReAYyhG3l/695IIzkkuZ/U7cwN23z+Sg5j5dOrPB6vPufLSCaZQPj/7gb 1JVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743021927; x=1743626727; 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=sr3YFov4BK2aTNvFd813PJ6MLOn0vE3kzg2fcZoBPhI=; b=wIg0ERYhpgyUFShnXR0eMSMceB5fpL58gPsecN3QRoY/ue/rMU+KjmKDw1ft6CbMZ/ EE280vUg3sSDzDJzNFgfEl6AveQG9QpkGU0kydbXPpNXGampyNidPX9W3/8U2kl3u6yg doHL3CAaTwmu4CZ18BIyzA5gRufR63hLGrvVUeECR1L+oy/Whv7yzbvjdyTz81BNmtFe HAZyHHvIgBsjMgWTg/cWuoI5J92/NoekMjPb6jJW7xHCw+jPOmbKjwcYXOWcD1BFJ/s7 K45YZBgHamSsUJA6H2yLDAApCb65BYN3yLsz8dAOX3Gv6SCLMgfiOsAGqIFLaD6GUIUR b7qw== X-Forwarded-Encrypted: i=1; AJvYcCVZ0gnUQHqPMY+iO/VPupI50kx5ldfUVygkeToDepEzl5xylZhxwtY/95kU9qFWiDxvvLOt@freebsd.org, AJvYcCXH9TtP/QZoOhcVXWDMcTe5HDsl+UD1Lyuppvt2lIuwegvtbJRjtyel4GPhdvh+wkW3uCmvWqex2bFLOFAGesHu@freebsd.org, AJvYcCXjUV1mSmjJuRLzVB2gJ/NgXadTeJ0duvDyXSuKmVXnrhOlea+I71ps8lPwE/JO5O1s3zRjnbJSiMrYn30=@freebsd.org X-Gm-Message-State: AOJu0Yy+cjaKa1b7F5mdBQ0GvMgKAfIpH7CCWM7vSymJXBsOLdiJ+0oT lQDttRGW0hrNdd3BcBw1CQNuckHGK9AbRFQr0reAG/NTmCSB3eN6vfu2ad8dKqBzM8cbFZM40wY RNfw7nAScJ0fGDvuRzhnYJ2hth3K6Ws8= X-Gm-Gg: ASbGncsCqPN6BXtgtmWHstFnOs77FmBSGJ1QoPcOnvd6ZlId1QMbnXLoTcFNpcYxw66 kshQyrZGGTSIGXm/f38f52xIuZt+e0wE4b1n6SBrHtscP7qiFLi8Fz+us33DpOZsYPH8AFisG41 PQxA6l/UNe4w3dVLvMINbOGGtqHi9mxXbsNHMwJ0gxLNYm70536pN2R08RPg== X-Google-Smtp-Source: AGHT+IEqnB1NSoH6Qf4c/i1gGgoM+OZ8vvZ6LhkC/7vyRNg9rsUZRoVkR7E/hCl3Tit9njTDic3iQNC4K+q6+DeIjmc= X-Received: by 2002:a05:6402:42c2:b0:5ec:c982:7efe with SMTP id 4fb4d7f45d1cf-5ed8e59ddbamr1018244a12.14.1743021926769; Wed, 26 Mar 2025 13:45:26 -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 13:45:15 -0700 X-Gm-Features: AQ5f1JqNFA8wl39U2RBykJ6RW3AU8aH7uZk-me3zQ7bMY1YouGF9wo0xhHA17n0 Message-ID: Subject: Re: RFC: Solaris style extended attributes for FreeBSD To: Alexander Motin Cc: Lionel Cons , 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.42 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.993]; NEURAL_HAM_SHORT(-0.93)[-0.932]; 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]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; TO_DN_SOME(0.00)[]; ARC_NA(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,ixsystems.com,freebsd.org]; MIME_TRACE(0.00)[0:+]; FROM_HAS_DN(0.00)[]; MISSING_XM_UA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; TAGGED_RCPT(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from] X-Rspamd-Queue-Id: 4ZNJhT53Hzz3L5N X-Spamd-Bar: -- On Wed, Mar 26, 2025 at 1:16=E2=80=AFPM Rick Macklem wrote: > > On Wed, Mar 26, 2025 at 11:36=E2=80=AFAM Alexander Motin wrote: > > > > Hi Rick, > > > > On 25.03.2025 16:53, Rick Macklem wrote: > > > 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/free= bsd/zfs > > > source subtree, which may make it easier?) > > > > I haven't looked on the patches yet, and I may not speak for the whole > > OpenZFS project, but I'd put emphasis on a cross-OS compatibility of th= e > > implementation, including the properties, namespace prefixes for > > different APIs, etc. > > > > Since the directory-style attributes are growing from Solaris, it would > > be nice if whatever API and on-disk format chosen would be compatible > > with it. Even though the merge traffic with Illumos is not that big > > lately and they are formally not a part of OpenZFS, but would be nice t= o > > not break the ties if possible. It might require some code archeology > > to understand the evolution of compatibility issues we have now. > As far as on-disk, I have done nothing. The patches just use what is alre= ady > there. > > As for the API, I am not familiar with what solaris did, since that > seems to have been stripped out? (I can see from man pages that the > syscall interface uses O_XATTR, but I do not see any indication how > that might land in ZFS? I suppose I can dive into Illumos sources, > but I'll admit I am not excited by the prospect.;-) > > The big question I see is whether these attributes (or the API to get at > them, if you prefer) should co-exist with the Linux/FreeBSD style on the > same file system? > > If I understand the code (I may not), the Linux/FreeBSD style extended > attributes are layered on top of the Solaris style ones stored in ZFS. > There are some quirks that I haven't quite figured out yet. > - How does the Linux/FreeBSD style determine attrnamespace? > (I think it might be done via a "user." or "system." prefix, but I have= n't > figured it out yet?) Ok, I just figured out a little more of this for the FreeBSD case... When zfs_xattr_compat is set (which is the case in the code now), the userspace attributes do not get any prefix.(This appears to be meant to be compatible with Solaris, but not Linux?) With zfs_xattr_compat zero, it prefixes "user.", which does appear to be Linux compatible? For system space, it puts "freebsd:system:" as a prefix. Definitely FreeBSD specific. It seems that FreeBSD's naming can be Solaris compatible for user space, but I still do not know how I got a duplicate name? (The code already appears to know to ignore the system space ones that start with "freebsd:system:" for the attribute directory stuff.) rick > - For FreeBSD, the code (in zfs_zaccess()) just punts, then calls like > zfs_setextattr() which implement the VOP kapi use FreeBSD generic > functions like exattr_check_cred() to do the checking. > --> I ended up cribbing the code from the Linux side to do the checking > in zfs_zaccess() for the Solaris style attributes. > The problem is...zfs_zaccess() must decide whether or not to punt. > --> As such, I have currently coded it so that the two styles do no > co-exit on the same file system. > I have succeeded in creating two attributes that show up with the > same name (one created via zfs_setextattr() and the other via the > named attribute syscall. So, I need to keep working on this.;-) > > > > > FreeBSD and Linux are equally important targets in OpenZFS now, and > > while some things might be difficult to implement on all platforms, for > > example Linux kernel does not support NFSv4-style ACLs, whatever design > > chosen should allow such perspective, even if not implemented > > immediately. So I am a little worried about "Most of the changes are i= n > > the os/freebsd/zfs source subtree". We don't want it to get implemente= d > > differently in Linux one day and become impossible to move pools betwee= n > > OS'es. We already have issues there, so would be good to not grow them= . > All I've seen w.r.t. the Linux side was a discussion (dated 2016) where t= hey > discussed the possibility of using an ioctl() API for doing this. > As far as I know, nothing came of it. > > Most of the ZFS changes are FreeBSD specific, since they involve > the FreeBSD VOP_LOOKUP(), which is definitely FreeBSD specific. > (One weirdness is that ".." in these named attribute directories refers > to the file object the attributes are associated with. As such, ".." ofte= n > refers to a non-directory. This is what the ZFS code does and is > mentioned in the NFSv4 RFC, with a SHOULD. (In NFSv4, "..' doesn't > exist, but is accessed via the lookup parent operation.) > > > > > While formally not a part of OpenZFS tree (yet?), there are forks for > > Windows and MacOS. It would be cool to understand at least basic > > requirements of those systems. > My vague understanding is that both of these do something close to > Solaris style, although I can never remember their terminology. > A couple of the guys in this discussion might be able to help w.r.t. > Windows, since I think their interest is related to a Windows NFSv4.1 > client. Anyone able to comment? > > > > > Don't get me wrong. I'd be really happy to see it done at least from > > the perspective of its being implemented for Solaris decades ago, and > > considering limitations other systems including FreeBSD have. It just > > might be a bit tangled after the years. > The current patch > https://people.freebsd.org/~rmacklem/xattr.patch > isn't particularly large and is really just the API rigging > which basically seems to work. > It has a bunch of printf()s in it which make it a little hard to read > and does not yet try to make ZFS build for systems without the > rest of the patch. > > Maybe you would find it easy to take a look at? rick > > > > > -- > > Alexander Motin