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 -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
