public inbox for linux-ext4@vger.kernel.org
 help / color / mirror / Atom feed
From: "Jose R. Santos" <jrs@us.ibm.com>
To: Andreas Dilger <adilger@sun.com>
Cc: "Theodore Ts'o" <tytso@mit.edu>,
	linux-ext4@vger.kernel.org,
	Valerie Clement <valerie.clement@bull.net>
Subject: Re: [E2FSPROGS, RFC] mke2fs: New bitmap and inode table allocation for FLEX_BG
Date: Wed, 23 Apr 2008 16:05:18 -0500	[thread overview]
Message-ID: <20080423160518.5c7fad2e@gara> (raw)
In-Reply-To: <20080423203955.GH2775@webber.adilger.int>

On Wed, 23 Apr 2008 14:39:55 -0600
Andreas Dilger <adilger@sun.com> wrote:

> On Apr 22, 2008  08:46 -0400, Theodore Ts'o wrote:
> > Change the way we allocate bitmaps and inode tables if the FLEX_BG
> > feature is used at mke2fs time.  It places calculates a new offset for
> > bitmaps and inode table base on the number of groups that the user
> > wishes to pack together using the new "-G" option.  Creating a
> > filesystem with 64 block groups in a flex group can be done by:
> > 
> > mke2fs -j -I 256 -O flex_bg -G 32 /dev/sdX
> 
> Presumably you mean "-G 64" based on your description of 64 groups/flex_bg?

Thanks for catching.
 
> > @@ -66,6 +137,22 @@ errcode_t ext2fs_allocate_group_table(ext2_filsys fs, dgrp_t group,
> > +		if (flexbg_size) {
> > +			dgrp_t gr = ext2fs_group_of_blk(fs, new_blk);
> > +			fs->group_desc[gr].bg_free_blocks_count--;
> > +			fs->super->s_free_blocks_count--;
> > +			fs->group_desc[gr].bg_flags &= ~EXT2_BG_BLOCK_UNINIT;
> > +			ext2fs_group_desc_csum_set(fs, gr);
> > +		}
> 
> It makes total sense to me that the BG_BLOCK_UNINIT flag would not be set
> on a group that does not have the default bitmap layouts, so I agree with
> this change.  I might suggest that we add a new flag BG_BLOCK_EMPTY or
> similar (which is really part of the FLEXBG feature so it doesn't affect
> the existing uninit_groups code) that indicates that the block bitmap
> contains NO allocated blocks, so that the kernel can know immediately
> when reconstructing the bitmap that there are no bitmaps or itable in
> that group (i.e. the bitmap is all zero).

I originally had a similar idea but was vetoed because there was no
kernel user on the flag.  The flag that I used was set if the block
group had meta-data as opposed to just being empty since there are still
block groups out there that can have no meta-data but still have bgd or
backup super blocks.  Would BG_BLOCK_EMPTY mean no bitmaps/inode tables
or does it imply completely empty block group?

> Cheers, Andreas
> --
> Andreas Dilger
> Sr. Staff Engineer, Lustre Group
> Sun Microsystems of Canada, Inc.
> 
> --
> 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



-JRS

  reply	other threads:[~2008-04-23 21:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-22 12:46 [RFC] Modified flex_bg patches Theodore Ts'o
2008-04-22 12:46 ` [E2FSPROGS, RFC] Basic flexible block group support Theodore Ts'o
2008-04-22 12:46   ` [E2FSPROGS, RFC] mke2fs: New bitmap and inode table allocation for FLEX_BG Theodore Ts'o
2008-04-22 14:18     ` Jose R. Santos
2008-04-22 14:51       ` Theodore Tso
2008-04-22 15:32         ` Jose R. Santos
2008-04-22 18:57           ` Theodore Tso
2008-04-22 22:27             ` Jose R. Santos
2008-04-23  1:21               ` Theodore Tso
2008-04-23  5:48                 ` Jose R. Santos
2008-04-23 12:23                   ` Theodore Tso
2008-04-23 16:24                     ` Jose R. Santos
2008-04-23 20:57             ` Andreas Dilger
2008-04-23 21:20               ` Jose R. Santos
2008-04-23 20:39     ` Andreas Dilger
2008-04-23 21:05       ` Jose R. Santos [this message]
2008-04-25 20:10         ` Andreas Dilger
2008-04-28 12:01           ` Theodore Tso
2008-04-23 21:01     ` Andreas Dilger
2008-04-22 13:47   ` [E2FSPROGS, RFC] Basic flexible block group support Jose R. Santos

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=20080423160518.5c7fad2e@gara \
    --to=jrs@us.ibm.com \
    --cc=adilger@sun.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=valerie.clement@bull.net \
    /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