[LU-193] e2fsprogs failing f_messy_inode on i686: Inode 14 is badly corrupt (badness value = 15). Clear? yes

• Status: Closed
• Project: Lustre
• Affects Version/s: Lustre 2.1.0
• Type: Bug
• Priority: Minor
• Reporter: Brian Murrell (Inactive)
• Assignee: Andreas Dilger
• Resolution: Fixed

Environment

i686 rhel5

• Story Points: 3
• Severity: 3

Description

While trying to build e2fsprogs-master on rhel5/i686 f_messy_inode fails with:

--- ./f_messy_inode/expect.1	2011-04-06 19:07:07.000000000 +0000
+++ f_messy_inode.1.log	2011-04-06 19:09:56.000000000 +0000
@@ -20,7 +20,7 @@
 i_file_acl for inode 14 (/MAKEDEV) is 4294901760, should be zero.
 Clear? yes
 
-Inode 14 is badly corrupt (badness value = 13).  Clear? yes
+Inode 14 is badly corrupt (badness value = 15).  Clear? yes
 
 Pass 3: Checking directory connectivity
 Pass 4: Checking reference counts

I realize that we don't really support i686 but I wonder if this is a bug that is lurking that we have been missing by not testing portably.

That said, I seem to recall seeing this issue as a result of portability before.

Comments

[Andreas Dilger]

It is definitely worthwhile to see why the test runs differently on 32-bit vs. 64-bit machines. If you extract this image by hand (zcat image.gz > /tmp/image) and run "e2fsck -v -v -d -d" it will print all the reasons why badness is increased, then diff the results.

[Andreas Dilger]

The 13 errors detected on inode 14 on my 64-bit system are:

Pass 1: Checking inodes, blocks, and sizes
check_ext_attr:1821: increase inode 14 badness 0 to 1
process_block:2645: increase inode 14 badness 1 to 2
Inode 14 has illegal block(s). Clear? yes

Illegal block #2 (4294901760) in inode 14. CLEARED.
process_block:2645: increase inode 14 badness 2 to 3
Illegal block #3 (4294901760) in inode 14. CLEARED.
process_block:2645: increase inode 14 badness 3 to 4
Illegal block #4 (4294901760) in inode 14. CLEARED.
process_block:2645: increase inode 14 badness 4 to 5
Illegal block #5 (4294901760) in inode 14. CLEARED.
process_block:2645: increase inode 14 badness 5 to 6
Illegal block #6 (4294901760) in inode 14. CLEARED.
process_block:2645: increase inode 14 badness 6 to 7
Illegal block #7 (4294901760) in inode 14. CLEARED.
process_block:2645: increase inode 14 badness 7 to 8
Illegal block #8 (4294901760) in inode 14. CLEARED.
process_block:2645: increase inode 14 badness 8 to 9
Illegal block #9 (4294901760) in inode 14. CLEARED.
process_block:2645: increase inode 14 badness 9 to 10
Illegal block #10 (4294901760) in inode 14. CLEARED.
check_blocks:2469: increase inode 14 badness 10 to 11
Inode 14, i_size is 18446462598732849291, should be 2048. Fix? yes

check_blocks:2486: increase inode 14 badness 11 to 12
Inode 14, i_blocks is 18, should be 4. Fix? yes

Pass 2: Checking directory structure
i_file_acl for inode 14 (/MAKEDEV) is 4294901760, should be zero.
Clear? yes

Inode 14 is badly corrupt (badness value = 13). Clear? yes

Unfortunately, I don't have any 32-bit nodes to test this on, and I'm not able to log into the test bed.

[Andreas Dilger]

I'm working on changing the testcase for this bug to determine why e2fsprogs is failing. Patches are being tested in change 543 (formerly change 531).

[Andreas Dilger]

Looking at a captured log file from a failed test on i686:
http://newbuild.whamcloud.com/job/e2fsprogs-reviews/19/arch=i686,distro=el5/console

it appears that e2fsck is failing because of the timestamps in the filesystem:

#define EXT4_XTIME_FUTURE(ctx, sb, xtime, margin) \
(!((ctx)->flags & E2F_FLAG_TIME_INSANE) && \
(xtime) > (ctx)->now + (margin))
#define EXT4_XTIME_ANCIENT(ctx, sb, xtime, margin) \
((xtime) < (sb)->s_mkfs_time - (margin))

if (EXT4_XTIME_FUTURE(ctx, sb, inode->i_ctime,ctx->time_fudge)||
EXT4_XTIME_ANCIENT(ctx, sb, inode->i_ctime,ctx->time_fudge))
e2fsck_mark_inode_bad(ctx, ino, BADNESS_HIGH);

f_messy_inode: bad file and directory acl pointers: failed
— ./f_messy_inode/expect.1 2011-05-13 07:50:24.000000000 +0000
+++ f_messy_inode.1.log 2011-05-13 07:54:10.000000000 +0000
@@ -1,38 +1,58 @@
Filesystem did not have a UUID; generating one.

Pass 1: Checking inodes, blocks, and sizes
-check_ext_attr:: increase inode 14 badness 0 to 1
-process_block:: increase inode 14 badness 1 to 2
+e2fsck_pass1:: increase inode 2 badness 0 to 2
+e2fsck_pass1:: increase inode 11 badness 0 to 2
+e2fsck_pass1:: increase inode 12 badness 0 to 2
+e2fsck_pass1:: increase inode 14 badness 0 to 2
+e2fsck_pass1:: increase inode 17 badness 0 to 2
+e2fsck_pass1:: increase inode 18 badness 0 to 2
+e2fsck_pass1:: increase inode 19 badness 0 to 2
+e2fsck_pass1:: increase inode 20 badness 0 to 2
+e2fsck_pass1:: increase inode 21 badness 0 to 2
+e2fsck_pass1:: increase inode 22 badness 0 to 2
+e2fsck_pass1:: increase inode 23 badness 0 to 2
+e2fsck_pass1:: increase inode 24 badness 0 to 2
+e2fsck_pass1:: increase inode 25 badness 0 to 2
+e2fsck_pass1:: increase inode 26 badness 0 to 2
+e2fsck_pass1:: increase inode 27 badness 0 to 2
+e2fsck_pass1:: increase inode 28 badness 0 to 2
+e2fsck_pass1:: increase inode 29 badness 0 to 2
+e2fsck_pass1:: increase inode 30 badness 0 to 2
+e2fsck_pass1:: increase inode 31 badness 0 to 2
+e2fsck_pass1:: increase inode 32 badness 0 to 2
+check_ext_attr:: increase inode 14 badness 2 to 3
+process_block:: increase inode 14 badness 3 to 4
Inode 14 has illegal block(s). Clear? yes

I haven't looked into the image or inodes yet, but I expect
it is some kind of sigh-extension on the inode timestamp or
possibly in the superblock.

[Andreas Dilger]

It seems that the s_mkfs_time is not set in the f_messy_inode superblock, so XTIME_ANCIENT was underflowing the (margin) calculation on 32-bit systems.

[Andreas Dilger]

Patch landed for e2fsprogs-1.41.90.wc2

[Build Master (Inactive)]

Integrated in e2fsprogs-master » x86_64,el5 #25
LU-193 fix f_messy_inode failure due to ibadness

Andreas Dilger : 09d4c203d07572ce176bd041d6411d46f2effd6b
Files :

• patches/series
• patches/e2fsprogs-ibadness-counter.patch
• patches/e2fsprogs-version.patch
• patches/e2fsprogs-tests-f_ibadness_debug.patch

[Build Master (Inactive)]

Integrated in e2fsprogs-master » x86_64,el6 #25
LU-193 fix f_messy_inode failure due to ibadness

Andreas Dilger : 09d4c203d07572ce176bd041d6411d46f2effd6b
Files :

• patches/e2fsprogs-version.patch
• patches/e2fsprogs-tests-f_ibadness_debug.patch
• patches/e2fsprogs-ibadness-counter.patch
• patches/series