If the badblocks inode fails checksum verification, just clear the
inode and move on. If we don't do this, we can end up importing a lot
of garbage into the badblocks list, which will then cause fsck to try
to regenerate anything that was sitting atop the supposedly damaged
blocks. Given that most hardware will remap bad sectors transparently
from ext4, the number of people this could affect adversely is pretty
low.
Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
---
e2fsck/pass1.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c
index 3734645..c02f5e9 100644
--- a/e2fsck/pass1.c
+++ b/e2fsck/pass1.c
@@ -1015,8 +1015,10 @@ void e2fsck_pass1(e2fsck_t ctx)
struct process_block_struct pb;
int flags;
- if ((inode->i_mode || inode->i_uid || inode->i_gid ||
- inode->i_links_count || inode->i_file_acl) &&
+ if ((failed_csum || inode->i_mode || inode->i_uid ||
+ inode->i_gid || inode->i_links_count ||
+ (inode->i_flags & EXT4_INLINE_DATA_FL) ||
+ inode->i_file_acl) &&
fix_problem(ctx, PR_1_INVALID_BAD_INODE, &pctx)) {
memset(inode, 0, sizeof(struct ext2_inode));
e2fsck_write_inode(ctx, ino, inode,
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
