From nobody Sun Mar 9 09:33:57 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 4Z9Zbq1CwRz5pYPQ; Sun, 09 Mar 2025 09:34:15 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z9Zbn6qCkz46sN; Sun, 09 Mar 2025 09:34:13 +0000 (UTC) (envelope-from kib@freebsd.org) Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=freebsd.org (policy=none); spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kib@freebsd.org) smtp.mailfrom=kib@freebsd.org Received: from tom.home (kib@localhost [127.0.0.1] (may be forged)) by kib.kiev.ua (8.18.1/8.18.1) with ESMTP id 5299Xvpj027065; Sun, 9 Mar 2025 11:34:00 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 5299Xvpj027065 Received: (from kostik@localhost) by tom.home (8.18.1/8.18.1/Submit) id 5299Xvpt027064; Sun, 9 Mar 2025 11:33:57 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Sun, 9 Mar 2025 11:33:57 +0200 From: Konstantin Belousov To: Rick Macklem Cc: freebsd-arch@freebsd.org, FreeBSD CURRENT , Cedric Blancher , Lionel Cons Subject: Re: RFC: Solaris style extended attributes for FreeBSD Message-ID: References: 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 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on tom.home X-Spamd-Result: default: False [1.28 / 15.00]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_SPAM_MEDIUM(0.88)[0.885]; NEURAL_HAM_LONG(-0.11)[-0.111]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : No valid SPF, No valid DKIM,none]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; FREEFALL_USER(0.00)[kib]; MIME_TRACE(0.00)[0:+]; TAGGED_RCPT(0.00)[]; MISSING_XM_UA(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; R_SPF_SOFTFAIL(0.00)[~all:c]; FROM_EQ_ENVFROM(0.00)[]; HAS_XAW(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_CC(0.00)[freebsd.org,gmail.com]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[] X-Rspamd-Queue-Id: 4Z9Zbn6qCkz46sN X-Spamd-Bar: + On Sat, Mar 08, 2025 at 03:02:14PM -0800, Rick Macklem wrote: > First off, I cross posted because I don't think many read freebsd-arch@. > There seems to be a nice market for Solaris style extended attributes. > Since ZFS is already wired for them, adding the basics is pretty > straightforward. I am not suggesting that they should replace the > current FreeBSD extended attributes. > > For those not familiar with them (I am not very familiar myself;-), > a Solaris style extended attribute is in a directory that hangs off > the file object and the entries in the directory (the attributes) can > be manipulated with open/read/write/lseek just like a regular file. > (They can be as large as a regular file, but there is no atomicity > guarantees.) > > At this point I have a couple of rough patches: > https://people.freebsd.org/~rmacklem/xattr.patch - the VFS/ZFS part > https://people.freebsd.org/~rmacklem/nfs-xattr.patch - the NFSv4 part > > I have a simple test program to test the above: > https://people.freebsd.org/~rmacklem/xattrtest.c > > The VFS/ZFS patch defines: > O_NAMEDATTR - similar to O_XATTR, but uses the NFSv4 named > attribute terminology to avoid confusion with the other style of > FreeBSD extended attributes. > (The semantics probably are not exactly the same either. I do not > have a Solaris system to test on, so I am going from the NFSv4 > and Solaris doc. I have handy.) > --> You can look at xattrtest.c to see how this is used. > > I have not done any userland patches and am not sure what might be > needed? (I suspect a variant of pax/tar that knows about these is the > minimum?) > > I defined a couple of new v_irflag bits to indicate that a vnode is > a named attribute directory or a named attribute. That way, they > are still of v_type VDIR or VREG and can be handled by most > of the code without change. > > So, now for the questions... > 1 - Do you think this should be put in FreeBSD? > (If the consensus is no, I will try and maintain out of tree patches.) > 2 - If the answer for #1 is yes, what do you think is needed beyond > what I already have (which is a way to open the named attribute > directory and named attributes within that directory). How to remove the attribute? Is there a way to rename? Could you please (try) to explain the semantic, for instance, to add the same support for UFS? Might be tmpfs would be much easier as the target, if some non-trivial on-disk structures needs to be added to UFS, esp. due to SU.