Re: [RFC PATCH] ext2: Retry block allocation if new blocks are allocated from system zone.

["Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>]

On Tue, Mar 25, 2008 at 05:56:49PM -0600, Andreas Dilger wrote:
> On Mar 26, 2008  00:26 +0530, Aneesh Kumar K.V wrote:
> > If the block allocator gets blocks out of system zone ext2 calls
> > ext2_error. But if the file system is mounted with errors=continue
> > retry block allocation. We need to mark the system zone
> > blocks as in use to make sure retry don't pick them again
> > 
> > System zone is the block range mapping block bitmap, inode bitmap
> > and inode table.
> 
> Nack * 3.  It appears that this will spin in a loop, because retry_alloc:
> will not change the group that is being used, and extN_valid_block_bitmap()
> does nothing to fix up the bitmap to avoid re-allocating the same blocks.


As also discussed on irc, ext2_try_to_allocate(fs/ext2/balloc.c:738)
marks the blocks allocated as in use. So we will not really spin in
loop here. Same is true for ext3 and ext4. (fs/ext4/balloc.c:1066) for
mballoc it is done as a part of patch.

> 
> Instead, it seems safest that extN_new_blocks() should skip the group
> entirely after marking the group as having no free blocks, so the allocator
> will no longer choose it.  This also means that when freeing blocks it
> needs to watch out for underflow of the ->bg_free_blocks_count value,
> which is itself a good safety measure.

Agreed. As you suggested on irc, i will try to introduce EXT4_BG_CORRUPT
and ignore the group which has EXT4_BG_CORRUPT set in block allocation.
I would also try to do e2fsck changes that will clear this flag after
fixing the bitmap corruption.

-aneesh