Hiya! I'm not really sure how to interpret this test failure with
e2fsprogs 1.46.1. Any ideas?
$ cat src/e2fsprogs-1.46.1/tests/j_recover_fast_commit.log
Journal checksum error found in test_filesys
Pass 1: Checking inodes, blocks, and sizes
Inode 14, i_blocks is 0, should be 2. Fix? yes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Unattached inode 14
Connect to /lost+found? yes
Inode 14 ref count is 2, should be 1. Fix? yes
Pass 5: Checking group summary information
Block bitmap differences: +1107
Fix? yes
Free blocks count wrong for group #0 (941, counted=940).
Fix? yes
Free blocks count wrong (942, counted=940).
Fix? yes
Free inodes count wrong (245, counted=242).
Fix? yes
test_filesys: ***** FILE SYSTEM WAS MODIFIED *****
test_filesys: 14/256 files (7.1% non-contiguous), 1108/2048 blocks
Exit status is 0
debugfs: ls
2 (12) . 2 (12) .. 11 (20) lost+found 12 (968) a
debugfs: ls a/
12 (12) . 2 (12) .. 13 (988) old
debugfs: ex a/new
debugfs: ex a/data
$ cat src/e2fsprogs-1.46.1/tests/j_recover_fast_commit.failed
--- j_recover_fast_commit/expect 2021-02-09 23:36:32.000000000 +0000
+++ j_recover_fast_commit.log 2021-02-11 20:39:26.306134217 +0000
@@ -1,22 +1,35 @@
+Journal checksum error found in test_filesys
Pass 1: Checking inodes, blocks, and sizes
+Inode 14, i_blocks is 0, should be 2. Fix? yes
+
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
+Unattached inode 14
+Connect to /lost+found? yes
+
+Inode 14 ref count is 2, should be 1. Fix? yes
+
Pass 5: Checking group summary information
-test_filesys: 14/256 files (14.3% non-contiguous), 1365/2048 blocks
+Block bitmap differences: +1107
+Fix? yes
+
+Free blocks count wrong for group #0 (941, counted=940).
+Fix? yes
+
+Free blocks count wrong (942, counted=940).
+Fix? yes
+
+Free inodes count wrong (245, counted=242).
+Fix? yes
+
+
+test_filesys: ***** FILE SYSTEM WAS MODIFIED *****
+test_filesys: 14/256 files (7.1% non-contiguous), 1108/2048 blocks
Exit status is 0
debugfs: ls
2 (12) . 2 (12) .. 11 (20) lost+found 12 (968) a
debugfs: ls a/
- 12 (12) . 2 (12) .. 13 (12) data 14 (976) new
+ 12 (12) . 2 (12) .. 13 (988) old
debugfs: ex a/new
-Level Entries Logical Physical Length Flags
- 0/ 0 1/ 1 0 - 0 1107 - 1107 1
debugfs: ex a/data
-Level Entries Logical Physical Length Flags
- 0/ 1 1/ 1 0 - 255 1618 256
- 1/ 1 1/ 5 0 - 15 1619 - 1634 16
- 1/ 1 2/ 5 16 - 31 1601 - 1616 16
- 1/ 1 3/ 5 32 - 63 1985 - 2016 32
- 1/ 1 4/ 5 64 - 127 1537 - 1600 64
- 1/ 1 5/ 5 128 - 255 1793 - 1920 128
On Thu, Feb 11, 2021 at 03:48:11PM -0500, Drew DeVault wrote:
> Hiya! I'm not really sure how to interpret this test failure with
> e2fsprogs 1.46.1. Any ideas?
It doesn't fail on musl-amd64 on Debian:
<tytso@cwcc> {/tmp/e}
1006% make -j16
...
t_mmp_2off: disable MMP using tune2fs: ok
370 tests succeeded 0 tests failed
make[1]: Leaving directory '/tmp/e/tests'
<tytso@cwcc> {/tmp/e}
1007% ./config.status --version
config.status
configured by /usr/projects/e2fsprogs/e2fsprogs/configure, generated by GNU Autoconf 2.69,
with options "'CC=musl-gcc'"
Copyright (C) 2012 Free Software Foundation, Inc.
This config.status script is free software; the Free Software Foundation
gives unlimited permission to copy, distribute and modify it.
<tytso@cwcc> {/tmp/e}
1008% dpkg -l musl\*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-====================================
ii musl:amd64 1.2.2-1 amd64 standard C library
ii musl-dev:amd64 1.2.2-1 amd64 standard C library development files
ii musl-tools 1.2.2-1 amd64 standard C library tools
<tytso@cwcc> {/tmp/e}
1009% gcc --version
gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Can you try using glibc on RiscV and see if it passes with glibc?
- Ted
On Thu Feb 11, 2021 at 11:03 PM EST, Theodore Ts'o wrote:
> Can you try using glibc on RiscV and see if it passes with glibc?
Hm, I don't have a glibc+RISC-V setup readily available for testing, nor
could I obtain one easily. But I would be open to offering shell access
in my musl environment for troubleshooting purposes - would you (or
any other maintainers) find that helpful?
Hi Drew,
I'd be happy to take a look at this and if you could provide shell
access, that would be great. From the logs you shared above, it looks
like e2fsck is crashing resulting in fast commit recovery being
aborted.
Thanks,
Harshad
On Fri, Feb 12, 2021 at 5:30 AM Drew DeVault <[email protected]> wrote:
>
> On Thu Feb 11, 2021 at 11:03 PM EST, Theodore Ts'o wrote:
> > Can you try using glibc on RiscV and see if it passes with glibc?
>
> Hm, I don't have a glibc+RISC-V setup readily available for testing, nor
> could I obtain one easily. But I would be open to offering shell access
> in my musl environment for troubleshooting purposes - would you (or
> any other maintainers) find that helpful?
Thanks Harshad! Can you send me your SSH public key off-list?