From: Eric Sandeen <sandeen@redhat.com>
To: ext4 development <linux-ext4@vger.kernel.org>
Subject: [PATCH] resize2fs: fix ENOSPC corruption case
Date: Mon, 18 May 2009 16:30:29 -0500 [thread overview]
Message-ID: <4A11D375.30709@redhat.com> (raw)
http://people.redhat.com/esandeen/livecd-creator-imagefile.bz2
contains an image (for now) which, when resized to 578639, corrupts
the filesystem.
This is a bit crazy, I guess, because the fs currently has only
1 free block, but still, we should be graceful about the failure.
Perhaps it would make sense to check the requested valuea against
the minimum value resize2fs would compute for "-P" and fail (at
least without a force).
But in any case, this exposed 2 bugs when moving that one block
required an extent split, which is what hit the ENOSPC.
For starters, ext2fs_extent_set_bmap() in the "(re/un)mapping last
block in extent" case was replacing the old extent before the
new one was created; when the new extent creation failed, it
left us in an inconsistent state. Simply changing the order of
the two should fix this problem.
Next, ext2fs_extent_insert was calling ext2fs_extent_delete()
on *any* error, including one caused by failure to allocate a new
block to split the node to hold that extent ... the handle was left
unchanged, and we deleted the -original- extent.
As a quick fix for this, just don't do the delete if we fail the split,
though this may need to be smarter. I don't think we have terribly
consistent behavior about where a handle is left on various errors.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
---
Index: e2fsprogs/lib/ext2fs/extent.c
===================================================================
--- e2fsprogs.orig/lib/ext2fs/extent.c
+++ e2fsprogs/lib/ext2fs/extent.c
@@ -1068,16 +1068,17 @@ errcode_t ext2fs_extent_insert(ext2_exte
retval = ext2fs_extent_replace(handle, 0, extent);
if (retval)
- goto errout;
+ goto errout_delete;
retval = update_path(handle);
if (retval)
- goto errout;
+ goto errout_delete;
return 0;
-errout:
+errout_delete:
ext2fs_extent_delete(handle, 0);
+errout:
return retval;
}
@@ -1239,16 +1240,17 @@ again:
#ifdef DEBUG
printf("(re/un)mapping last block in extent\n");
#endif
- extent.e_len--;
- retval = ext2fs_extent_replace(handle, 0, &extent);
- if (retval)
- goto done;
+ /* Make sure insert works before replacing old extent */
if (physical) {
retval = ext2fs_extent_insert(handle,
EXT2_EXTENT_INSERT_AFTER, &newextent);
if (retval)
goto done;
}
+ extent.e_len--;
+ retval = ext2fs_extent_replace(handle, 0, &extent);
+ if (retval)
+ goto done;
} else if (logical == extent.e_lblk) {
#ifdef DEBUG
printf("(re/un)mapping first block in extent\n");
next reply other threads:[~2009-05-18 21:30 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-18 21:30 Eric Sandeen [this message]
2009-05-18 21:35 ` [PATCH] resize2fs: fix ENOSPC corruption case Eric Sandeen
2009-05-20 11:37 ` Theodore Tso
2009-05-20 15:57 ` Eric Sandeen
2009-05-20 20:58 ` Theodore Tso
2009-05-20 21:36 ` [PATCH V2] " Eric Sandeen
2009-05-26 2:38 ` Theodore Tso
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=4A11D375.30709@redhat.com \
--to=sandeen@redhat.com \
--cc=linux-ext4@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.