public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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) &&

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox