On Fri, Mar 28, 2025 at 1:31 PM Dennis Clarke <dcla...@blastwave.org> wrote:
>
> 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.
Well, the NFSv4 ACLs exist now in FreeBSD for ZFS and no one has been pushing
for "ls" to know how to display them. (See getfacl(1))
ZFS also already supports extended attributes and, as above, "ls" does not
know how to display them. (See lsextattr(1), getextattr(1)...)
I do not see why commands like "ls" need to know about these things.
tar/pax is a different story, since archival of them seems necessary.
All the patches I have created does is add a different, Solaris like
syscall/KABI
for manipulating extended attributes. The patches just use code that
is already in ZFS to
handle the extended attributes as files in a directory.
ZFS currently appears to store extended attributes two ways:
"zfs set xattr=sa <file system>" - For this one, small extended
attributes are stored
in some sort of storage block. If the extended attribute is too
large for the storage
block, it spills over into a file in a directory.
--> The alternate syscall/KAPI does not work and is disabled for
this property setting.
"zfs set xattr=on <file system>" - Also called "dir", all extended
attributes are stored
as regular files, with a directory holding their names.
--> The alternate syscall/KAPI the patches adds provides a more
direct way to access
this directory and the files that store the extended attributes.
The main advantage of this syscall/KAPI is that large extended
attributes are supported.
Since this is already how ZFS stores extended attributes, I assume
send/recv knows
how to deal with them. tar/pax will need to know the alternate
syscall/KAPI to handle
large extended attributes if this syscall/KABI is used. (The thread I
mentioned over
on freebsd-hackers@ mentions a patched version of pax/tar, but I have
not looked at it.)
Do many people need/want to handle large extended attributes?
I'd guess not, but I really have no idea what FreeBSD users use?
(I only hear about problems w.r.t. NFS, so I have no idea how many use
it without
problems.)
For NFSv4, this alternate model is supported as "named attributes". There is as
extension to NFSv4.2 for the Linux/FreeBSD model for small extended attributes,
but this extension doesn't work for clients on Windows, Mac OSX or Solaris.
As such, there is another niche market for some NFSv4 clients.
The patches are rough, but basically done. I am now in testing mode. It was not
exactly a "make work" project. More a "I was curious to see how easily
the Solaris
style syscall/kapi could be implemented" project.
I do not see any reason why UFS would need/want this alternate syscall/kapi,
since anyone wanting/needing large extended attributes could use ZFS, which
is what most managed storage will use anyhow.
In summary, other than the patches I've already done, a patched version of
tar/pax is about all I think is needed.
rick
>
>
> > 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.
>
>
>
>
>
>
