From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Subject: Re: [RFC PATCH] ext2: Retry block allocation if new blocks are
	allocated from system zone.
Date: Wed, 26 Mar 2008 13:08:00 +0530
Message-ID: <20080326073800.GA7325@skywalker>
References: <1206471371-9659-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <20080325235649.GY2691@webber.adilger.int>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: cmm@us.ibm.com, linux-ext4@vger.kernel.org
To: Andreas Dilger <adilger@sun.com>
Content-Disposition: inline
In-Reply-To: <20080325235649.GY2691@webber.adilger.int>
Sender: linux-ext4-owner@vger.kernel.org

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