From nobody Wed Mar 26 20:16:20 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 4ZNJ362KkWz5r8H8; Wed, 26 Mar 2025 20:16:34 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 4ZNJ356Sjqz3yDX; Wed, 26 Mar 2025 20:16:33 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-5eb92df4fcbso426526a12.0; Wed, 26 Mar 2025 13:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1743020192; x=1743624992; 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=mN5BBxJJZvuxG8jqugUJrewIHkiQibxDktjyPOzDGLI=; b=IYf6SVyvIT6It5ESL+ZMgiA4NwGJfFCgdMeSfRNlGfvNefeVgQ8f2xdOCcImx050ms d4CskTqIhyG/SX/0+AYkkyWg7LN4U8NAmvy5KeFz0hU4cevmMElBLxOdmX/+Xgj9eKbS TpAK3cSO9wpWZYru3rY2iZcGPCZ826w1CBa/p6gKTakUsmCmV3HL7eqMsic8qRR+dxah WmMiIthNszob21C6EcLw+ZcCFYc4uq0WzHpn+54DFnWgPKsrVyc0C47JIi9KYm2kYmTO ogyCUOqHBDbwhEY2JVQXNbP4Suplt/EZfZVJMbZY5Xce32QdiHSjm5bWtv183OsIqc2U ZQDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1743020192; x=1743624992; 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=mN5BBxJJZvuxG8jqugUJrewIHkiQibxDktjyPOzDGLI=; b=CtkU3V4p6HpsdkS/5vxcxYqZbh8mFHXVMvioGJSUHqFDVcOA/YmE43XzX0NGmRG23c Qu4FsxBKpVM8ONIB3Xss4JfnkE7GaVG78LAyKgcDJJIJwWgjuWYyxB+ZzEmRf6k+Y8vt ZoWR+dP0uyJiLe8Q1k/LEE4JtdVtvccYzOmA8YncG2lkbPKaHZ1z2Pc9Xt7wLKCbbSB+ wNMl5Zwv8VPUEf+nn/TanKVQD8+H2xvyq0hr6OtsfMyfsOoeXX6p/1rJLUxrSFUjCq+S drvDF4sUudsjhU+r/U4pyEUX5wA9gL5walKopTxwQLFoeqR4QkI/IDJdVrW4AmT1A4M1 Ct3A== X-Forwarded-Encrypted: i=1; AJvYcCUJZY+m9LeTrTl5pdntWE4f5Urknk4cJBQ/1LEDiBsAcRVosmqYntoMcLAM7gPSqCUjLOi2XSE6eZWRSylS4Icc@freebsd.org, AJvYcCV+cDxHHZzMDmfp+YxxOLZIC67ePBf43+a48L/HnV1zeALeoZ3vC233xop8SLTwSnERsdWP@freebsd.org, AJvYcCXfyyhzWLQtQhiN4GMkEvJs485Y8Q41rQ/vd1M2ZMkGr2LHVwCE0Wx+3u5+IFnvqL+J0YVyA+3m6kO1krg=@freebsd.org X-Gm-Message-State: AOJu0YxWgG05/HEBU6PifyECF98IV0UEdQlFKaS2I72mMgZuqIhZD7Xd 4y6PS9gbmliTaZr63fHr18XXuMGztaE6sLCW0dHQF/32f63McOVp7AsQMQVWVEyARK5odI4UF5A 4fE3n6Y9NlzyJse6aZ2WlnGngglHA X-Gm-Gg: ASbGncsPcnuXw1FhyoAapMagBJ8fPljxVkFnxRRufmsv5LuPmPZMEXRU2txSKc0xNrd /ZPs1HfuZemJcYTnfmzIJahvRhphhBhwCE0JcvfozjHYQ7FBEw+0SlF+Qc/nGzdEE6LLSoi2yTU cqwmIsAOx3G2m/wOZr6I/kTO++/H0JH+EQYCjJLfZd135PFcvIez9eHAn2Ag== X-Google-Smtp-Source: AGHT+IHN/MO9IvEx+J+WkGVE/V6zS8ZnQNNV2BeSbcS1AXiGaVwPaMYeZw/elwP8dY8go6DMaNA7meBrEH10wKeqiFc= X-Received: by 2002:a05:6402:234c:b0:5dc:c9ce:b022 with SMTP id 4fb4d7f45d1cf-5ed8e382771mr808175a12.9.1743020192023; Wed, 26 Mar 2025 13:16:32 -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:16:20 -0700 X-Gm-Features: AQ5f1JojEECNvvWvYS-RFCAl-_B8H3e_etIP3RvpKNcCXaK_QMiKrFOlirJegYE 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-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4ZNJ356Sjqz3yDX X-Spamd-Bar: ---- 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 wha= t > > their position will be? (Most of the changes are in the os/freebs= d/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 the > 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 to > 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 alread= y 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 haven'= t figured it out yet?) - 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 in > the os/freebsd/zfs source subtree". We don't want it to get implemented > differently in Linux one day and become impossible to move pools between > 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 the= y 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, ".." often 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