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] [day] [month] [year] [list]
Date:	Mon, 23 Jun 2008 10:02:42 -0500
From:	"Jose R. Santos" <>
Cc:	Gary Hawco <>,
Subject: Re:

On Mon, 16 Jun 2008 17:44:04 -0400
Nick Dokos <> wrote:

> Gary Hawco <> wrote:
> > Had a couple of questions as to what flex_bg & meta_bg features
> > involve.  I think flex_bg has to do with areas of metadata skipped
> > during e2fsck, but I am not sure about meta_bg.  And is meta_bg a
> > mount option or a feature specified during mkfs.ext4dev?  And if
> > so, I guess you would use mkfs.ext4dev -t meta_bg?
> > 
> > Any insight would be most appreciated.
> From
> ext4: FLEX_BG Kernel support v2.
>     This feature relaxes check restrictions on where each block groups
>     meta data is located within the storage media. This allows for the
>     allocation of bitmaps or inode tables outside the block group
>     boundaries in cases where bad blocks forces us to look for new
>     blocks which the owning block group can not satisfy. This will
> also allow for new meta-data allocation schemes to improve performance
>     and scalability.
> It's set with `mkfs.ext4dev -O flex_bg ...' or `tune2fs -O
> flex_bg ...'

As the description says, FLEX_BG just removes restrictions on where
each block groups meta data can be located.  There is a option
currently in e2fsprogs (-G) that allow the grouping of meta data of
multiple block groups in a contiguous fashion.  There is also a
experimental inode allocator in the patch queue that is FLEX_BG
grouping aware and changes inode allocation better fit the new
meta data allocation and improve performance on heavy meta data
workloads.  Aneesh's OLS paper will have a section on this new
allocator as well as more details on FLEX_BG.
> meta_bg is described in last year's OLS ext4 paper:
>     The solution to this problem [having enough bits for only a 256TB
>     filesystem] is to use the metablock group feature (META_BG), which
>     is already in ext3 for all 2.6 releases. With the META_BG feature,
>     ext4 filesystems are partitioned into many metablock groups.  Each
>     metablock group is a cluster of block groups whose group
> descriptor structures can be stored in a single disk block. For ext4
>     filesystems with 4 KB block size, a single metablock group
> partition includes 64 block groups, or 8 GB of disk space. The
> metablock group feature moves the location of the group descriptors
> from the congested first block group of the whole filesystem into the
> first group of each metablock group itself. The backups are in the
> second and last group of each metablock group. This increases the 2^21
>     maximum block groups limit to 2^32, allowing support for the full
>     1EB filesystem.
> meta_bg is incompatible with resize_inode and afaik cannot be set
> through tune2fs, so you got to do it at mkfs time:
>     mkfs.ext4dev -O flex_bg,meta_bg,^resize_inode ...

I believe that you no longer need to add the ^resize_inode option
since current e2fsprogs removes the option if meta_bg is specified.
> Hope this helps (and that it is correct, although if it isn't I'm
> sure somebody will correct it!).
> Nick
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4"
> in the body of a message to
> More majordomo info at
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists