linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@MIT.EDU>
To: Paul Collins <paul@burly.ondioline.org>
Cc: linux-ext4@vger.kernel.org
Subject: Re: (resend) extent header problems following shrink with resize2fs
Date: Thu, 25 Dec 2008 23:14:11 -0500	[thread overview]
Message-ID: <20081226041411.GM9871@mit.edu> (raw)
In-Reply-To: <877i5ozprb.fsf@burly.wgtn.ondioline.org>

On Thu, Dec 25, 2008 at 08:18:48PM +1300, Paul Collins wrote:
> Theodore Tso <tytso@MIT.EDU> writes:
> > Yeah, resize2fs needs to be fixed to handle extents correctly.  At the
> > moment it can screw them up pretty badly.
> 
> In the meantime, perhaps something like the patch below is appropriate?

Actually, I think the following patch should fix things up nicely.  I
need to create a test case so I can be sure this fixes the problem,
but I think this should address the root cause of theproblem you
reported.

						- Ted

diff --git a/resize/resize2fs.c b/resize/resize2fs.c
index abe05f5..65398a6 100644
--- a/resize/resize2fs.c
+++ b/resize/resize2fs.c
@@ -1188,6 +1188,16 @@ static int process_block(ext2_filsys fs, blk_t	*block_nr,
 	return ret;
 }
 
+static int process_block_ind(ext2_filsys fs, blk_t *block_nr,
+			     e2_blkcnt_t blockcnt, blk_t ref_block, 
+			     int ref_offset, void *priv_data)
+{
+	if (blockcnt >= 0)
+		return 0;
+	return process_block(fs, block_nr, blockcnt, ref_block, ref_offset,
+			     priv_data);
+}
+
 /*
  * Progress callback
  */
@@ -1302,6 +1312,18 @@ static errcode_t inode_scan_and_fix(ext2_resize_t rfs)
 		if (ext2fs_inode_has_valid_blocks(inode) &&
 		    (rfs->bmap || pb.is_dir)) {
 			pb.ino = ino;
+			if (inode->i_flags & EXT4_EXTENTS_FL) {
+				/*
+				 * With extent-based files, we have
+				 * to translate all of the interior
+				 * node blocks first.
+				 */
+				retval = ext2fs_block_iterate2(rfs->old_fs,
+						ino, 0, block_buf,
+						process_block_ind, &pb);
+				if (retval)
+					goto errout;
+			}
 			retval = ext2fs_block_iterate2(rfs->old_fs,
 						       ino, 0, block_buf,
 						       process_block, &pb);

      parent reply	other threads:[~2008-12-26  4:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-23  5:49 (resend) extent header problems following shrink with resize2fs Paul Collins
2008-12-23  6:18 ` Theodore Tso
2008-12-20 18:14   ` Massive filesystem corruption Matteo Croce
2008-12-20 19:27     ` Eric Sandeen
2008-12-21  2:05       ` Matteo Croce
2008-12-21  3:23         ` Eric Sandeen
2008-12-21  5:09         ` Nick Dokos
2008-12-26  3:57         ` Theodore Tso
2008-12-25  7:18   ` (resend) extent header problems following shrink with resize2fs Paul Collins
2008-12-25 13:09     ` Theodore Tso
2008-12-26  4:14     ` Theodore Tso [this message]

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=20081226041411.GM9871@mit.edu \
    --to=tytso@mit.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=paul@burly.ondioline.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;
as well as URLs for NNTP newsgroup(s).