From: Theodore Tso <tytso@mit.edu>
To: Felipe Contreras <felipe.contreras@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Weird ext4 bug: 256P used?
Date: Mon, 12 Oct 2009 22:11:08 -0400 [thread overview]
Message-ID: <20091013021108.GB2606@mit.edu> (raw)
In-Reply-To: <20091013010518.GA2606@mit.edu>
Here's a patch to e2fsprogs which will cause e2fsck to find and fix
the filesystem corruption. I'm not sure how i_blocks_hi was set to
the incorect value in the first place, but this should fix the
filesystem for you (largely a cosmetic issue).
- Ted
commit 8a8f36540bbf5d4397cf476e216e9a720b5c1d8e
Author: Theodore Ts'o <tytso@mit.edu>
Date: Mon Oct 12 21:59:37 2009 -0400
e2fsck: Fix handling of non-zero i_blocks_high field
E2fsck was not properly printing the i_blocks field in filesystem
corruption messages, and it was not properly checking i_blocks_hi and
i_blocks_lo, either. This commit fixes this.
Thanks to Felipe Conteras for pointing this out.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
diff --git a/e2fsck/message.c b/e2fsck/message.c
index 5e28812..9aaedc5 100644
--- a/e2fsck/message.c
+++ b/e2fsck/message.c
@@ -258,7 +258,7 @@ static _INLINE_ void expand_at_expression(e2fsck_t ctx, char ch,
/*
* This function expands '%IX' expressions
*/
-static _INLINE_ void expand_inode_expression(char ch,
+static _INLINE_ void expand_inode_expression(ext2_filsys fs, char ch,
struct problem_context *ctx)
{
struct ext2_inode *inode;
@@ -292,7 +292,8 @@ static _INLINE_ void expand_inode_expression(char ch,
printf("%u", large_inode->i_extra_isize);
break;
case 'b':
- if (inode->i_flags & EXT4_HUGE_FILE_FL)
+ if (fs->super->s_feature_ro_compat &
+ EXT4_FEATURE_RO_COMPAT_HUGE_FILE)
printf("%llu", inode->i_blocks +
(((long long) inode->osd2.linux2.l_i_blocks_hi)
<< 32));
@@ -528,7 +529,7 @@ void print_e2fsck_message(e2fsck_t ctx, const char *msg,
expand_at_expression(ctx, *cp, pctx, &first, recurse);
} else if (cp[0] == '%' && cp[1] == 'I') {
cp += 2;
- expand_inode_expression(*cp, pctx);
+ expand_inode_expression(fs, *cp, pctx);
} else if (cp[0] == '%' && cp[1] == 'D') {
cp += 2;
expand_dirent_expression(fs, *cp, pctx);
diff --git a/e2fsck/pass1.c b/e2fsck/pass1.c
index 9b12005..2531e57 100644
--- a/e2fsck/pass1.c
+++ b/e2fsck/pass1.c
@@ -1792,6 +1792,15 @@ static void check_blocks_extents(e2fsck_t ctx, struct problem_context *pctx,
ext2fs_extent_free(ehandle);
}
+static blk64_t ext2fs_inode_i_blocks(ext2_filsys fs,
+ struct ext2_inode *inode)
+{
+ return (inode->i_blocks |
+ (fs->super->s_feature_ro_compat &
+ EXT4_FEATURE_RO_COMPAT_HUGE_FILE ?
+ (__u64)inode->osd2.linux2.l_i_blocks_hi << 32 : 0));
+}
+
/*
* This subroutine is called on each inode to account for all of the
* blocks used by that inode.
@@ -1972,7 +1981,7 @@ static void check_blocks(e2fsck_t ctx, struct problem_context *pctx,
if (LINUX_S_ISREG(inode->i_mode) &&
(inode->i_size_high || inode->i_size & 0x80000000UL))
ctx->large_files++;
- if ((pb.num_blocks != inode->i_blocks) ||
+ if ((pb.num_blocks != ext2fs_inode_i_blocks(fs, inode)) ||
((fs->super->s_feature_ro_compat &
EXT4_FEATURE_RO_COMPAT_HUGE_FILE) &&
(inode->i_flags & EXT4_HUGE_FILE_FL) &&
next prev parent reply other threads:[~2009-10-13 2:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-12 13:51 Weird ext4 bug: 256P used? Felipe Contreras
2009-10-12 22:29 ` Theodore Tso
2009-10-12 23:02 ` Felipe Contreras
2009-10-12 23:12 ` Theodore Tso
2009-10-12 23:27 ` Felipe Contreras
2009-10-13 1:05 ` Theodore Tso
2009-10-13 2:11 ` Theodore Tso [this message]
2009-10-13 11:11 ` Felipe Contreras
2009-10-13 12:13 ` Theodore Tso
2009-10-13 12:18 ` Felipe Contreras
2009-10-13 11:08 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20091013021108.GB2606@mit.edu \
--to=tytso@mit.edu \
--cc=felipe.contreras@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.