Re: ext3: bogus i_mode errors with 2.6.18.1

[Andreas Dilger <adilger@clusterfs.com>]

On Oct 24, 2006  11:14 +0200, Andre Noll wrote:
> On 14:02, Andreas Dilger wrote:
> Something like the this? (only compile tested). And no, I do _not_ know,
> what I'm doing ;)

Don't worry, everyone starts out not knowing what they are doing.
The ext3_free_blocks() part looks OK from a cursory review.

> @@ -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)) {
> +		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));

I'm not sure why the "find_next_usable_block()" part is in here?  At this
point we KNOW that ret_block is not a block we should be allocating, yet
it is marked free in the bitmap.  So we should just mark the block(s) in-use
in the bitmap and look for a different block(s).

> +		if (j >= 0)
> +			ext3_set_bit(j, gdp_bh->b_data);

Note that we need to loop over "num" blocks and set any bits that should
be set, as is done in the ext3_free_blocks() code.  This function has
changed since 2.4 in that it can now potentially allocate multiple blocks.

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/