From nobody Fri Mar 28 20:31:02 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 4ZPXH473dyz5rP85 for ; Fri, 28 Mar 2025 20:31:12 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from mail.oetec.com (mail.oetec.com [108.160.241.186]) (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-signature ECDSA (prime256v1) client-digest SHA256) (Client CN "mail.oetec.com", Issuer "E5" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZPXH40GnZz3Bm2 for ; Fri, 28 Mar 2025 20:31:11 +0000 (UTC) (envelope-from dclarke@blastwave.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=blastwave.org header.s=default header.b=jY9GcWM+; dmarc=pass (policy=quarantine) header.from=blastwave.org; spf=pass (mx1.freebsd.org: domain of dclarke@blastwave.org designates 108.160.241.186 as permitted sender) smtp.mailfrom=dclarke@blastwave.org Received: from [172.16.35.3] (pool-99-253-118-250.cpe.net.cable.rogers.com [99.253.118.250]) (authenticated bits=0) by mail.oetec.com (8.17.1/8.17.1) with ESMTPSA id 52SKV2sP079446 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Fri, 28 Mar 2025 16:31:04 -0400 (EDT) (envelope-from dclarke@blastwave.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=blastwave.org; s=default; t=1743193864; bh=Zng+mlpgjJPhY9FtyYL4RVKZ2R8t5hez56C7SkUjpRw=; h=Date:Subject:To:References:From:In-Reply-To; b=jY9GcWM+BJTSwn2GaU7cT9Qa45G3OSfjEqWNtSire7O46cU0wWSTm5VSmvLRaoUap 5dokB+zE01MbuBQTe5MU4MfqUVmFlx8v4SQoElOdpZOI4DLsEjYHd5+lD/7x7ErM+G YAF4Lxh5ZPjAe66RM5g8okf8hGBAKQLx+MCCH0Z0oldwGt1qt/4hIZGyGEv40ymlWW SdKRjdhvWp9j2SE5DFEc3xgYNRcCVEWJxDysAsMRwFOF6EGovn9UeaVcPQI7HXr3Fa gZyTaJNDxnTJT5rShhbip2HXwSO4ukyxV6nkkYVS+676mmNZGdEqnHPNuxBugiHTbt HLF/gwramIOoA== Message-ID: <410014e4-75a6-4923-8f84-3935cab41c31@blastwave.org> Date: Fri, 28 Mar 2025 16:31:02 -0400 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 User-Agent: Mozilla Thunderbird Subject: Re: RFC: Solaris style extended attributes for FreeBSD Content-Language: en-CA To: freebsd-current@freebsd.org References: From: Dennis Clarke Organization: GENUNIX In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-oetec-MailScanner-Information: Please contact the ISP for more information X-oetec-MailScanner-ID: 52SKV2sP079446 X-oetec-MailScanner: Found to be clean X-oetec-MailScanner-From: dclarke@blastwave.org X-Spam-Status: No X-Spamd-Result: default: False [-4.55 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-0.99)[-0.988]; NEURAL_HAM_SHORT(-0.87)[-0.866]; DMARC_POLICY_ALLOW(-0.50)[blastwave.org,quarantine]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; R_DKIM_ALLOW(-0.20)[blastwave.org:s=default]; R_SPF_ALLOW(-0.20)[+mx]; RCVD_IN_DNSWL_MED(-0.20)[108.160.241.186:from]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:812, ipnet:108.160.240.0/20, country:CA]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[blastwave.org:+] X-Rspamd-Queue-Id: 4ZPXH40GnZz3Bm2 X-Spamd-Bar: ---- On 3/8/25 18:02, 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. Hold on a moment. I have been following this discussion now for a while and I am trying to figure who wants this? Why? Is this a "make work" project wherein a pile of code and testing will needed? Where the word "pile" may mean years. > 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. > Well if you decide to go into NFS with xattr then you may as well dig into UFS with xattr also. Perhaps that would be insane however once you deal with ACL handling in tools like tar and ls then you will need to ponder UFS also. That means output similar to Solaris /usr/xpg4/bin/ls like so : The following example shows how to display compact ACL information on a ZFS directory. % ls -dV test.dir drwxr-xr-x 2 marks staff 2 Mar 14 10:17 test.dir owner@:--------------:------:deny owner@:rwxp---A-W-Co-:------:allow group@:-w-p----------:------:deny group@:r-x-----------:------:allow everyone@:-w-p---A-W-Co-:------:deny everyone@:r-x---a-R-c--s:------:allow The following example illustrates the ls -v behavior when listing ACL information on a UFS file. $ ls -v file.3 -rw-r--r-- 1 root root 2703 Mar 14 10:59 file.3 0:user::rw- 1:group::r-- #effective:r-- 2:mask:r-- 3:other:r-- I see considerable differences between the FreeBSD base ls and Solaris ls which does handle ACL data in both UFS and ZFS. Does this need to be dragged onto the table along with every other file handling tool and system call? I see a tarpit ( no pun intended ) this opens up. > 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.) I just, today, shutdown my last Solaris server which was a Fujitsu SPARC64 machine and it was draining power and making heat for a number of years in my life. Certainly it was using ZFS but not the ZFS that we can use or "zfs send" anywhere. The botched up stuff that is totally not compatible with OpenZFS of any flavour. This means that I had to do a blunt force medieval tarball backup. Nothing else would ever be usable for recovery. Never in the many many years of using Solaris with ZFS have I felt the need to drag in xattr's on people. Not once in two decades. Pretty sure I did some very early testing within the OpenSolaris project and can not recall the desperate need thereafter. So who wants this? Why? Is there some atom-splitting world changing reason that the extended attributes are needed in FreeBSD? -- -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken ps: Jörg Schilling wrote a very xattr aware TAR in his schilytools https://github.com/clausecker/schilytools It is cross platform aware and already in ports as "star". https://cgit.freebsd.org/ports/tree/archivers/star/pkg-descr Being fast is a matter of opinion but I used it to backup my Fujitsu SPARC64 server today and the stats over 1Gbit NFSv3 are : pluto# tail -16 hubble_sparc64.star.log a 1564 -rw-r--r-- 1 root/root May 2 04:08 2024 var/dt/Xerrors a 5 -rw-r--r-- 1 root/root May 2 04:08 2024 var/dt/Xpid a 0 drwxr-xr-x 2 root/root May 2 04:08 2024 vol/ a 0 drwxr-xr-x 2 root/root May 5 22:31 2024 z/ star: Missing links to 'proc/183/fd/3'. star: Missing links to 'proc/108/object/a.out'. star: fifo had 20090580 puts 45730806 gets. star: fifo was 1092 times empty and 1548 times full. star: fifo held 268441600 bytes max, size was 268441600 bytes star: 45730806 blocks + 0 bytes (total of 468283453440 bytes = 457308060.00k). star: Total time 8539.200sec (53553 kBytes/sec) star: The following problems occurred during archive processing: star: Cannot: stat 2, open 0, read/write 42, chdir 0, iconv 349. star: Size changed 34. star: Missing links 2, Name too long 0, File too big 0, Not dumped 1. star: Processed all possible files, despite earlier errors. So yeah, it works and you can trust it.