On Thu, 2008-02-28 at 17:10 -0700, Chris Kottaridis wrote:
> That's all I currently have of the log, I'll see if I can get more of
> it.
>
> I was pointed to this diff that has a "goto out" added if we hit this
> scenario:
>
> feda58d37ae0efe22e711a74e26fb541d4eb1baa
> fs/ext3/balloc.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ext3/balloc.c b/fs/ext3/balloc.c
> index a26e683..d2dface 100644
> --- a/fs/ext3/balloc.c
> +++ b/fs/ext3/balloc.c
> @@ -530,11 +530,13 @@ do_more:
> 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))
> + sbi->s_itb_per_group)) {
> ext3_error (sb, "ext3_free_blocks",
> "Freeing blocks in system zones - "
> "Block = "E3FSBLK", count = %lu",
> block, count);
> + goto error_return;
> + }
>
> /*
> * We are about to start releasing blocks in the bitmap,
> @@ -1637,11 +1639,13 @@ 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_SB(sb)->s_itb_per_group)) {
> ext3_error(sb, "ext3_new_block",
> "Allocating block in system zone - "
> "blocks from "E3FSBLK", length %lu",
> ret_block, num);
> + goto out;
> + }
>
> performed_allocation = 1;
>
>
> The *errp gets set to -ENOSPC at the beginning of the routine so it'd go
> to out with *errp set to -ENOSPC.
>
Ah...That seems a wrong, should returns EIO in this case.
The fs has a marked the blocks for fs metadata as "used" on bitmaps at
the mkfs time, so if we are able to allocate a new block(which checks
the bitmap), the fs is not short of free block.
> That's got to be better then continuing thinking it's OK to scribble on
> metadata.
>
> However, I don't think it's necessarily true that it's out of space.
> Before this is a loop that looks for a group that will satisfy the
> request. If it thinks it's found one it stops checking the groups and
> jumps out of the loop and then makes this test for overlapping the
> metadata. With the new patch it returns -ENOSPC, but really there just
> isn't any space up to the groups that have been checked and we get to
> the test before all the groups have been checked.
> It would seem that this check would be better serviced inside the loop
> once we think we have a possible range of blocks that will fit. If it
> turns out the range overlaps the metadata we should try the next group.
Ur..If the allocated data blocks overlaps the fs metadata blocks, that
means fs is corrupted: could be a bad block group descriptor, or a bad
bitmap. In any case it should mark fs error and should not continue
allocation in next group.
What does fsck reports?
Mingming
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
