On 30/05/2025 10:02, Gael Donval wrote:
Ok, I've done that and you were right. I guess BTRFS implements its
file attributes as extended attributes. The relevant part of the strace
is this:
openat(AT_FDCWD, "btrfs/baz", O_RDONLY) = 4
openat(3, "baz", O_WRONLY|O_CREAT|O_EXCL, 0644) = 5
flistxattr(4, NULL, 0) = 18
flistxattr(4, "btrfs.compression\0", 18) = 18
openat(AT_FDCWD, "/etc/xattr.conf", O_RDONLY) = 6
read(6, "# /etc/xattr.conf\n#\n# Format:\n# "..., 4096) = 622
fgetxattr(4, "btrfs.compression", NULL, 0) = 4
fgetxattr(4, "btrfs.compression", "zlib", 4) = 4
fsetxattr(5, "btrfs.compression", "zlib", 4, 0) = -1 EOPNOTSUPP (Operation not
supported)
and updating /etc/xattr.conf to ignore it does work.
I can't see any way to tweak this behaviour at command-line level yet
the behaviour can be triggered by normal users: would it make sense to
add a flag to filter xattr out at CLI level?
It would get unwieldy as CLI options I think,
and you'd usually want a static list of FS specific options.
There are additional complications with a static list though,
as you would probably want to attempt to copy xattrs within
or between file systems of the same type, so unconditionally
avoiding them in a static list may not be appropriate.
Note `cp -a` will attempt to copy all xattrs
but ignore "operation not supported" errors.
So we only have this issue with --preserve=xattr which diagnoses any issues.
Perhaps we would benefit from a --preserve=supported-xattr option?
BTW there is a further complication with the "btrfs.compression" xattr
as its behavior is dependent on whether you write that xattr
before or after you write the data:
https://lists.gnu.org/archive/html/coreutils/2020-05/msg00013.html
(Though note we reflink by default now, since the above discussion
which alleviates the issue somewhat).
cheers,
Padraig
