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
next prev parent 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