From: Andre Noll <maan@systemlinux.org>
To: Theodore Ts'o <tytso@mit.edu>,
linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org,
Eric Sandeen <esandeen@redhat.com>
Subject: Re: ext3: bogus i_mode errors with 2.6.18.1
Date: Tue, 24 Oct 2006 11:14:49 +0200 [thread overview]
Message-ID: <20061024091449.GZ22487@skl-net.de> (raw)
In-Reply-To: <20061023200242.GA5015@schatzie.adilger.int>
[-- Attachment #1: Type: text/plain, Size: 3786 bytes --]
On 14:02, Andreas Dilger wrote:
> I found a URL for the 2.4 version of this patch, if some kind soul would
> update it for 2.6 it might save someone's data in the future.
Something like the this? (only compile tested). And no, I do _not_ know,
what I'm doing ;)
Thanks
Andre
diff --git a/fs/ext3/balloc.c b/fs/ext3/balloc.c
index 063d994..da2bd51 100644
--- a/fs/ext3/balloc.c
+++ b/fs/ext3/balloc.c
@@ -359,17 +359,6 @@ do_more:
if (!desc)
goto error_return;
- if (in_range (le32_to_cpu(desc->bg_block_bitmap), block, count) ||
- in_range (le32_to_cpu(desc->bg_inode_bitmap), block, count) ||
- in_range (block, le32_to_cpu(desc->bg_inode_table),
- sbi->s_itb_per_group) ||
- in_range (block + count - 1, le32_to_cpu(desc->bg_inode_table),
- sbi->s_itb_per_group))
- ext3_error (sb, "ext3_free_blocks",
- "Freeing blocks in system zones - "
- "Block = "E3FSBLK", count = %lu",
- block, count);
-
/*
* We are about to start releasing blocks in the bitmap,
* so we need undo access.
@@ -392,7 +381,17 @@ do_more:
jbd_lock_bh_state(bitmap_bh);
- for (i = 0, group_freed = 0; i < count; i++) {
+ for (i = 0, group_freed = 0; i < count; i++, block++) {
+ struct ext3_group_desc *gdp = ext3_get_group_desc(sb, i, NULL);
+ if (block == le32_to_cpu(gdp->bg_block_bitmap) ||
+ block == le32_to_cpu(gdp->bg_inode_bitmap) ||
+ in_range(block, le32_to_cpu(gdp->bg_inode_table),
+ EXT3_SB(sb)->s_itb_per_group)) {
+ ext3_error(sb, __FUNCTION__,
+ "Freeing block in system zone - block = %lu",
+ block);
+ continue;
+ }
/*
* An HJ special. This is expensive...
*/
@@ -400,7 +399,7 @@ #ifdef CONFIG_JBD_DEBUG
jbd_unlock_bh_state(bitmap_bh);
{
struct buffer_head *debug_bh;
- debug_bh = sb_find_get_block(sb, block + i);
+ debug_bh = sb_find_get_block(sb, block);
if (debug_bh) {
BUFFER_TRACE(debug_bh, "Deleted!");
if (!bh2jh(bitmap_bh)->b_committed_data)
@@ -452,7 +451,7 @@ #endif
jbd_unlock_bh_state(bitmap_bh);
ext3_error(sb, __FUNCTION__,
"bit already cleared for block "E3FSBLK,
- block + i);
+ block);
jbd_lock_bh_state(bitmap_bh);
BUFFER_TRACE(bitmap_bh, "bit already cleared");
} else {
@@ -479,7 +478,6 @@ #endif
*pdquot_freed_blocks += group_freed;
if (overflow && !err) {
- block += count;
count = overflow;
goto do_more;
}
@@ -1260,7 +1258,7 @@ #endif
*errp = -ENOSPC;
goto out;
}
-
+repeat:
/*
* First, test whether the goal block is free.
*/
@@ -1372,12 +1370,24 @@ allocated:
in_range(ret_block, le32_to_cpu(gdp->bg_inode_table),
EXT3_SB(sb)->s_itb_per_group) ||
in_range(ret_block + num - 1, le32_to_cpu(gdp->bg_inode_table),
- EXT3_SB(sb)->s_itb_per_group))
- ext3_error(sb, "ext3_new_block",
+ EXT3_SB(sb)->s_itb_per_group)) {
+ int j;
+ ext3_error(sb, __FUNCTION__,
"Allocating block in system zone - "
"blocks from "E3FSBLK", length %lu",
ret_block, num);
-
+ /* Note: This will potentially use up one of the handle's
+ * buffer credits. Normally we have way too many credits,
+ * so that is OK. In _very_ rare cases it might not be OK.
+ * We will trigger an assertion if we run out of credits,
+ * and we will have to do a full fsck of the filesystem -
+ * better than randomly corrupting filesystem metadata.
+ */
+ j = find_next_usable_block(-1, gdp, EXT3_BLOCKS_PER_GROUP(sb));
+ if (j >= 0)
+ ext3_set_bit(j, gdp_bh->b_data);
+ goto repeat;
+ }
performed_allocation = 1;
#ifdef CONFIG_JBD_DEBUG
--
The only person who always got his work done by Friday was Robinson Crusoe
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2006-10-24 9:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20061023144556.GY22487@skl-net.de>
2006-10-23 16:44 ` ext3: bogus i_mode errors with 2.6.18.1 Andreas Dilger
2006-10-23 20:02 ` Andreas Dilger
2006-10-24 9:14 ` Andre Noll [this message]
2006-10-24 20:27 ` Andreas Dilger
2006-10-25 9:44 ` Andre Noll
2006-10-26 9:36 ` Andreas Dilger
2006-10-26 16:02 ` Andre Noll
2006-10-26 18:01 ` Andreas Dilger
2006-10-27 15:34 ` Andre Noll
2006-10-28 14:24 ` Andreas Dilger
2006-10-30 9:55 ` Andre Noll
2006-11-15 0:03 ` Andreas Dilger
2006-11-15 14:30 ` Andre Noll
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=20061024091449.GZ22487@skl-net.de \
--to=maan@systemlinux.org \
--cc=esandeen@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
/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).