linux-ext4 - Re: [RFC] BIG_BG vs extended META

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070630233908.115ec78e@gara>
Date:	Sat, 30 Jun 2007 23:39:08 -0500
From:	"Jose R. Santos" <jrs@...ibm.com>
To:	Andreas Dilger <adilger@...sterfs.com>
Cc:	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [RFC] BIG_BG vs extended META_BG in ext4

On Sat, 30 Jun 2007 01:51:25 -0400
Andreas Dilger <adilger@...sterfs.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
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html