public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: Andreas Dilger <adilger@sun.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH] resize2fs: Fix support for the uninit_bg feature
Date: Tue, 17 Jun 2008 09:16:47 -0600	[thread overview]
Message-ID: <20080617151647.GD3726@webber.adilger.int> (raw)
In-Reply-To: <1213682792-4878-2-git-send-email-tytso@mit.edu>

On Jun 17, 2008  02:06 -0400, Theodore Ts'o wrote:
> @@ -1579,13 +1589,35 @@ static errcode_t ext2fs_calculate_summary_stats(ext2_filsys fs)
>  	/*
>  	 * First calculate the block statistics
>  	 */
> +	uninit = fs->group_desc[group].bg_flags & EXT2_BG_BLOCK_UNINIT;
> +	ext2fs_super_and_bgd_loc(fs, group, &super_blk, &old_desc_blk,
> +				 &new_desc_blk, 0);
> +	if (fs->super->s_feature_incompat & EXT2_FEATURE_INCOMPAT_META_BG)
> +		old_desc_blocks = fs->super->s_first_meta_bg;
> +	else
> +		old_desc_blocks = fs->desc_blocks +
> +			fs->super->s_reserved_gdt_blocks;

I'm a bit confused by this.  It doesn't seem that you use old_desc_blocks
in the META_BG case?  I'm trying to figure out what "old_desc_blocks"
means in the META_BG case.


Also, the number of places where we have to figure out whick blocks
are in use for a particular group is growing quite large, and with the
interactions between various features (META_BG, SPARSE_SUPER, FLEX_BG,
RESIZE_INODE, etc) getting this right in all of these places is hard.
Places that need this, off the top of my head, include mk2fs, e2fsck,
resize2fs, kernel (online resize, uninit_bg), debugfs.

It would be very handy to have a single function that can figure out
the block layout for any group based on all of the features, and then
return the block numbers of the bitmaps, itable, sb, gdt (if present).
This would be like a more complex version of ext2fs_super_and_bgd_loc(),
but it also returns the number of gdt blocks (normal and reserved),
bitmaps, inode table, and itable blocks.

A group descriptor would almost be the right struct, but it doesn't
(yet?) include the GDT block count, itable block count, or a flag if
there is a superblock.  Adding these fields into the on-disk group_desc
struct wouldn't be a bad idea, then all the need to recalculate the
group layout in 10 places would disappear.

A second function would take the above block numbers (possibly in the
form of a modified group descriptor) and return a populated block bitmap.

>  	for (blk = fs->super->s_first_data_block;
>  	     blk < fs->super->s_blocks_count; blk++) {
> -		if (!ext2fs_fast_test_block_bitmap(fs->block_map, blk)) {
> +		if ((uninit &&
> +		     !((blk == super_blk) ||
> +		       ((old_desc_blk && old_desc_blocks &&
> +			 (blk >= old_desc_blk) &&
> +			 (blk < old_desc_blk + old_desc_blocks))) ||
> +		       ((new_desc_blk && (blk == new_desc_blk))) ||
> +		       (blk == fs->group_desc[group].bg_block_bitmap) ||
> +		       (blk == fs->group_desc[group].bg_inode_bitmap) ||
> +		       ((blk >= fs->group_desc[group].bg_inode_table &&
> +			 (blk < fs->group_desc[group].bg_inode_table
> +			  + fs->inode_blocks_per_group))))) ||
> +		    (!ext2fs_fast_test_block_bitmap(fs->block_map, blk))) {
>  			group_free++;
>  			total_free++;
>  		}

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.


  parent reply	other threads:[~2008-06-17 15:16 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-17  6:06 e2fsprogs: Patches to resize2fs Theodore Ts'o
2008-06-17  6:06 ` [PATCH] resize2fs: Fix support for the uninit_bg feature Theodore Ts'o
2008-06-17  6:06   ` [PATCH] ext2fs_zero_blocks: Avoid clearing more blocks than requested Theodore Ts'o
2008-06-17  6:06     ` [PATCH] resize2fs: Prohibit the combination of flex_bg and !resize_inode Theodore Ts'o
2008-06-17 15:16   ` Andreas Dilger [this message]
2008-06-17 16:30     ` [PATCH] resize2fs: Fix support for the uninit_bg feature Theodore Tso
2008-06-23 20:42       ` Andreas Dilger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080617151647.GD3726@webber.adilger.int \
    --to=adilger@sun.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox