m_rootdir_acl test fails when run from a btrfs filesystem (since its' introduction in v1.46.1) #158
Comments
|
Hmm, this is working for me when running on a Debian ppc64 porterbox: By the way, I don't know how long I will have access to a ppc64 Big Endian machine. From: golang/go#34850:
So far, the OSUOSL machine is still around, and Debian is still running autobuilders for ppc64 and s390x, but s390x is the only remaining "officially" supported big endian machine left which is officially supported by Debian. Right now ppc64 (big endian) is only supported unofficially, which I suspect means the "bus factor" for ppc64 is very high.... |
|
Wanted to verify my results on ppc32 and ran the tests again with git-master on my ppc32 partition on the same machine, kernel is also exactly the same. To my surprise m_rootdir_acl passed! Apart from 32bit ppc instead of 64bit ppc another difference is the underlying root filesystem. On ppc64 I use Another difference is using GCC 11.4 on ppc vs. using GCC 12.3 on ppc64. I'll check out next whether I get different results using GCC 11.4 on ppc64. |
Perhaps the GCC Compile Farm may be of interest for you? They got one POWER7 and one POWER8 machine running ppc64 BE (and several others ppc64le) where you are granted free access when working on a piece of free software (GCC or any other GPL, BSD, MIT, ...) and need ssh access to the farm for compilation, debug and test on various architectures. Apart from that I tested out my assumptions from my last post. GCC 11.4 vs. GCC 12.4 does not matter but underlying filesystem does! When I build e2fsprogs and run the tests from an ext4 partition m_rootdir_acl passes - when I build e2fsprogs and run the tests from a btrfs partition m_rootdir_acl fails. Question is this being an e2fsprogs test-suite bug or a btrfs bug? |
|
The way this test works is to set up extended attributes on the local directory where the test is being run, and then creates a file system with those extended attributes using "mke2fs -d". What this is testing is how mke2fs reads the extended attributes from the local file system, and populates the freshly created file system with those extended attributes. Running on xfs, the test passes: Running on btrfs, it looks like the problem is the order that it is returning the extended attributes when read from the local file system is different from ext4 and xfs: I ran the above reproduction on x86, so this is not a ppc64 specific issue. ppc32 and ppc64 was a red-herring; it has nothing to do with big-endian systems, but rather how the file system returns the order of the xattrs. The main issue is that most of the ext4 development communities tend to either use ext4 or xfs file systems. Or if they run the regression test suite on MacOS, or on Linux with tmpfs, the test gets skipped because MacOS doesn't support extended attributes, and tmpfs doesn't support user extended attributes. |
ernsteiswuerfel
changed the title
|
@tytso Should I open an issue on the btrfs tracker regarding this issue here? |
|
Well, actually, I don't think there is any guarantee of ordering with respect to the ordering of how extended attributes are returned --- certainly not between system.posix_acl_default and system.posix_acl_access! Ext4 will certainly move where extended attributes are stored between in the inode (where it is faster, for things like ACL's and SELinux labels, where that is critcal), and in an external xattr block, so the ordering of how ext4 store extended attributes is also subject to change. So this is arguably a test bug, where we need to sort the order of extended attributes returned by dumpe2fs to see whether or not the xattrs were accurately placed in the file system. It's a non-trivial change, though so it's one of those things that I probably won't have time to fix in the immediate future. Patches would greatfully be accepted.... |
|
Thanks for clarification! |
Bug: tytso/e2fsprogs#158 Closes: https://bugs.gentoo.org/905221 Signed-off-by: Sam James <[email protected]>
This started with Gentoo downstream bug #905221.
I wanted to bisect the change leading to the m_rootdir_acl failure but found out the test was failing since its' introduction in v1.46.1. Test still fails with git-master.
m_rootdir_acl.failed:
m_rootdir_acl.log:
Tests were run from git-master on a Talos II running Gentoo Linux, Big Endian. EXT4_FS_POSIX_ACL=y is enabled in the kernel .config, ext4 is built into the kernel (not as a module).
testlog_git-master.log
The text was updated successfully, but these errors were encountered: