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-ext4" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
