[LU-1010] lfsck.sh test: e2fsck_pass1:1402: increase inode 20 badness 0 to 1

• Type: Bug
• Resolution: Duplicate
• Priority: Minor
• Affects Version/s: Lustre 2.1.0, Lustre 2.2.0
• Labels: e2fsprogs
• Environment: e2fsprogs-1.41.90.wc4 development release
• Story Points: 3
• Severity: 3
• Assignee: WC Triage
• Reporter: Andreas Dilger

Description

It appears that Lustre is creating somewhat invalid files on the OST:

https://maloo.whamcloud.com/test_sets/cbcbbd2e-3f50-11e1-990e-5254004bbbd3

09:47:21:fat-intel-1vm4: e2fsck_pass1:1402: increase inode 20 badness 0 to 1
09:47:21:fat-intel-1vm4: e2fsck_pass1:1406: increase inode 20 badness 1 to 3
09:47:21:fat-intel-1vm4: e2fsck_pass1:1402: increase inode 31 badness 0 to 1
09:47:21:fat-intel-1vm4: e2fsck_pass1:1406: increase inode 31 badness 1 to 3
09:47:21:fat-intel-1vm4: e2fsck_pass1:1402: increase inode 32 badness 0 to 1
09:47:21:fat-intel-1vm4: e2fsck_pass1:1406: increase inode 32 badness 1 to 3

These messages relate to the checks added in the "e2fsprogs-ibadness-counter" patch:

if (EXT4_XTIME_FUTURE(ctx, sb, inode->i_atime,ctx->time_fudge)||
EXT4_XTIME_FUTURE(ctx, sb, inode->i_mtime,ctx->time_fudge))
e2fsck_mark_inode_bad(ctx, ino, BADNESS_NORMAL);+
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);

In turn I think this is caused by the code in filter_create:

                /* Set a/c/m time to a insane large negative value at creation
                 * time so that any timestamp arriving from the client will
                 * always be newer and update the inode.
                 * See LU-221 for details */
                iattr.ia_valid = ATTR_ATIME | ATTR_MTIME | ATTR_CTIME;
                LTIME_S(iattr.ia_atime) = INT_MIN + 24 * 3600;
                LTIME_S(iattr.ia_mtime) = INT_MIN + 24 * 3600;
                LTIME_S(iattr.ia_ctime) = INT_MIN + 24 * 3600;

This was added in commit 414251797ed178eec5d431e1f5aa4a889d2b159f, which "git describe" shows as 2_0_66_0-3-g4142517

This isn't a critical issue in itself, but it means that unused OST files are 3/8 of the way to being marked invalid, and other normal causes like objects over 2GB will also help push the inodes closer to the edge.

Issue Links

• duplicates: LU-1042 1.8 clients show wrong dates with 2.1 servers