Why do we initialize block bitmaps in ext4_new_inode()

Why do we initialize block bitmaps in ext4_new_inode()

[Theodore Ts'o]

Is there some subtle reason why ext4_new_inode() checked for
uninitialized block bitmaps and initialized the block bitmaps in
ext4_new_inode().  It's not immediately needed in that function, and I
don't see any reason why initializing the inode table or inode
allocation bitmap requires initializing the block bitmap.

Am I missing something?

					- Ted


>From ff15031626d5f10ba1256c0c7a3818ca12205b55 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <tytso@mit.edu>
Date: Mon, 14 Mar 2011 13:37:36 -0400
Subject: [PATCH] ext4: Remove block bitmap initialization in ext4_new_inode()

We are initializing the block bitmap in ext4_new_inode(), and as far
as I can tell, there's no reason to do it.  So remove it to simplify
things.

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
 fs/ext4/ialloc.c |   36 ------------------------------------
 1 files changed, 0 insertions(+), 36 deletions(-)

diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
index 2fd3b0e..f79432a 100644
--- a/fs/ext4/ialloc.c
+++ b/fs/ext4/ialloc.c
@@ -936,42 +936,6 @@ repeat_in_this_group:
 	goto out;
 
 got:
-	/* We may have to initialize the block bitmap if it isn't already */
-	if (EXT4_HAS_RO_COMPAT_FEATURE(sb, EXT4_FEATURE_RO_COMPAT_GDT_CSUM) &&
-	    gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {
-		struct buffer_head *block_bitmap_bh;
-
-		block_bitmap_bh = ext4_read_block_bitmap(sb, group);
-		BUFFER_TRACE(block_bitmap_bh, "get block bitmap access");
-		err = ext4_journal_get_write_access(handle, block_bitmap_bh);
-		if (err) {
-			brelse(block_bitmap_bh);
-			goto fail;
-		}
-
-		free = 0;
-		ext4_lock_group(sb, group);
-		/* recheck and clear flag under lock if we still need to */
-		if (gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {
-			free = ext4_free_blocks_after_init(sb, group, gdp);
-			gdp->bg_flags &= cpu_to_le16(~EXT4_BG_BLOCK_UNINIT);
-			ext4_free_blks_set(sb, gdp, free);
-			gdp->bg_checksum = ext4_group_desc_csum(sbi, group,
-								gdp);
-		}
-		ext4_unlock_group(sb, group);
-
-		/* Don't need to dirty bitmap block if we didn't change it */
-		if (free) {
-			BUFFER_TRACE(block_bitmap_bh, "dirty block bitmap");
-			err = ext4_handle_dirty_metadata(handle,
-							NULL, block_bitmap_bh);
-		}

Re: Why do we initialize block bitmaps in ext4_new_inode()

[Amir Goldstein]

On Mon, Mar 14, 2011 at 7:44 PM, Theodore Ts'o <tytso@mit.edu> wrote:
>
> Is there some subtle reason why ext4_new_inode() checked for
> uninitialized block bitmaps and initialized the block bitmaps in
> ext4_new_inode().  It's not immediately needed in that function, and I
> don't see any reason why initializing the inode table or inode
> allocation bitmap requires initializing the block bitmap.
>
> Am I missing something?

If you are, then I am missing it too.
Was there ever a time when uninit_bg meant something other than it means today?
Like wasn't it used by fsck for fast inode scan of ext3?
Does it mater anything for fsck if the block bitmap is not initialized
and the inode bitmap is?



>
>                                        - Ted
>
>
> From ff15031626d5f10ba1256c0c7a3818ca12205b55 Mon Sep 17 00:00:00 2001
> From: Theodore Ts'o <tytso@mit.edu>
> Date: Mon, 14 Mar 2011 13:37:36 -0400
> Subject: [PATCH] ext4: Remove block bitmap initialization in ext4_new_inode()
>
> We are initializing the block bitmap in ext4_new_inode(), and as far
> as I can tell, there's no reason to do it.  So remove it to simplify
> things.
>
> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
> ---
>  fs/ext4/ialloc.c |   36 ------------------------------------
>  1 files changed, 0 insertions(+), 36 deletions(-)
>
> diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c
> index 2fd3b0e..f79432a 100644
> --- a/fs/ext4/ialloc.c
> +++ b/fs/ext4/ialloc.c
> @@ -936,42 +936,6 @@ repeat_in_this_group:
>        goto out;
>
>  got:
> -       /* We may have to initialize the block bitmap if it isn't already */
> -       if (EXT4_HAS_RO_COMPAT_FEATURE(sb, EXT4_FEATURE_RO_COMPAT_GDT_CSUM) &&
> -           gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {
> -               struct buffer_head *block_bitmap_bh;
> -
> -               block_bitmap_bh = ext4_read_block_bitmap(sb, group);
> -               BUFFER_TRACE(block_bitmap_bh, "get block bitmap access");
> -               err = ext4_journal_get_write_access(handle, block_bitmap_bh);
> -               if (err) {
> -                       brelse(block_bitmap_bh);
> -                       goto fail;
> -               }
> -
> -               free = 0;
> -               ext4_lock_group(sb, group);
> -               /* recheck and clear flag under lock if we still need to */
> -               if (gdp->bg_flags & cpu_to_le16(EXT4_BG_BLOCK_UNINIT)) {
> -                       free = ext4_free_blocks_after_init(sb, group, gdp);
> -                       gdp->bg_flags &= cpu_to_le16(~EXT4_BG_BLOCK_UNINIT);
> -                       ext4_free_blks_set(sb, gdp, free);
> -                       gdp->bg_checksum = ext4_group_desc_csum(sbi, group,
> -                                                               gdp);
> -               }
> -               ext4_unlock_group(sb, group);
> -
> -               /* Don't need to dirty bitmap block if we didn't change it */
> -               if (free) {
> -                       BUFFER_TRACE(block_bitmap_bh, "dirty block bitmap");
> -                       err = ext4_handle_dirty_metadata(handle,
> -                                                       NULL, block_bitmap_bh);
> -               }
> -
> -               brelse(block_bitmap_bh);
> -               if (err)
> -                       goto fail;
> -       }
>        BUFFER_TRACE(group_desc_bh, "call ext4_handle_dirty_metadata");
>        err = ext4_handle_dirty_metadata(handle, NULL, group_desc_bh);
>        if (err)
> --
> 1.7.3.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Why do we initialize block bitmaps in ext4_new_inode()

[Andreas Dilger]

On 2011-03-14, at 10:44 AM, Theodore Ts'o wrote:
> Is there some subtle reason why ext4_new_inode() checked for
> uninitialized block bitmaps and initialized the block bitmaps in
> ext4_new_inode().  It's not immediately needed in that function, and I
> don't see any reason why initializing the inode table or inode
> allocation bitmap requires initializing the block bitmap.
> 
> Am I missing something?

The assumption when this was coded is that if the inode bitmap was in use, then the block bitmap must also be initialized in order to mark the inode bitmap block in use also.

If we think that the block allocator isn't in any danger of reallocating the inode bitmap block, or inode table blocks because the block bitmap is uninitialized, then it isn't strictly needed.  I think the added checks for blocks being allocated from system zones was added after the uninit_bg feature was written.

The correlation between block and inode bitmaps is also different due to flex_bg, which didn't exist when flex_bg was written.  If inodes are allocated from a group, it was formerly (w/o flex_bg) very likely that blocks will also be allocated from this group.  Any blocks that are allocated to inodes from that group will have that group as the goal block.  With flex_bg the correlation is less strong, but I'd be surprised if more inodes are allocated than blocks (i.e. initialized inode bitmap, but no need to initialize block bitmap), even in a flex_bg filesystem.

Cheers, Andreas