On Mon, 16 Jun 2008 17:44:04 -0400 Nick Dokos <nicholas.dokos@xxxxxx> wrote: > Gary Hawco <ghawco@xxxxxxx> 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 http://www.ussg.iu.edu/hypermail/linux/kernel/0709.2/2408.html > > 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 majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
