All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jose R. Santos" <jrs@us.ibm.com>
To: Andreas Dilger <adilger@clusterfs.com>
Cc: linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [RFC] BIG_BG vs extended META_BG in ext4
Date: Sat, 30 Jun 2007 23:39:08 -0500	[thread overview]
Message-ID: <20070630233908.115ec78e@gara> (raw)
In-Reply-To: <20070630055125.GC5535@schatzie.adilger.int>

On Sat, 30 Jun 2007 01:51:25 -0400
Andreas Dilger <adilger@clusterfs.com> wrote:
> I don't think there is actually any fundamental difference between these
> proposals.  The reality is that we cannot change the semantics of the
> META_BG flag at this point, since both e2fsprogs and ext3/ext4 in the
> kernel understand META_BG to mean only "group descriptor backups are
> in groups {0, 1, last} of the metagroup" and nothing else.

Agree.  I call it extended META_BG for lack of a better name, but a new
feature flag will be required.

> If we want to allow the bitmaps and inode table outside the group they
> represent then this needs to be a separate feature flag, and we may as
> well include the additional improvement of the BIG_BG feature at the
> same time.  I don't think this really any reason to claim there is "no
> need to have a concept of block groups".

Well when I think about block groups, it seems to me that its basically
a range of blocks with some blocks dedicated for holding important meta
data.  If you remove the meta data, then all that is left is a range of
blocks with some backup data scatter around specific locations on the
disk.  Of course, my definition of what a block group is could just be
wrong. :)

We could blur the difference between these two features though.

> Also note that e2fsprogs already reserves the bg_free_*_bg fields for
> BIG_BG in the expanded group descriptors, though there is no official
> definition for BIG_BG:
> 
> struct ext4_group_desc
> {
>         [ ext3_group_desc ]
>         __u32   bg_block_bitmap_hi;     /* Blocks bitmap block MSB */
>         __u32   bg_inode_bitmap_hi;     /* Inodes bitmap block MSB */
>         __u32   bg_inode_table_hi;      /* Inodes table block MSB */
>         __u16   bg_free_blocks_count_hi;/* Free blocks count MSB */
>         __u16   bg_free_inodes_count_hi;/* Free inodes count MSB */
>         __u16   bg_used_dirs_count_hi;  /* Directories count MSB */
>         __u16   bg_pad;
>         __u32   bg_reserved2[3];
> };
> 
> 
> 
> Cheers, Andreas
> --
> Andreas Dilger
> Principal Software Engineer
> Cluster File Systems, Inc.
> 

Thanks for the pointer.

-JRS

  parent reply	other threads:[~2007-07-01  4:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-29 22:09 [RFC] BIG_BG vs extended META_BG in ext4 Jose R. Santos
2007-06-30  5:51 ` Andreas Dilger
2007-06-30 14:24   ` Mingming Cao
2007-07-01  4:39   ` Jose R. Santos [this message]
2007-07-01 12:30     ` Theodore Tso
2007-07-01 14:48       ` Jose R. Santos
2007-07-02 15:49         ` Theodore Tso
2007-07-02 14:12           ` Mingming Cao
2007-07-05  6:56             ` Valerie Henson
     [not found] ` <D5D3223C-4EB0-413B-A81A-05F6DDC0FEEB@bull.net>
2007-07-01  4:40   ` Jose R. Santos
2007-07-01 16:31     ` Andreas Dilger
2007-07-02 14:39       ` Jose R. Santos
2007-07-03 17:55         ` 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=20070630233908.115ec78e@gara \
    --to=jrs@us.ibm.com \
    --cc=adilger@clusterfs.com \
    --cc=linux-ext4@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.