Meta Block Groups，可以翻译为元块组集。
如果不采用Meta Block Groups特性，在每个冗余备份的超级块的后面是一个完整的(包含所有块组描述符的)块组描述符表的备份。如前所述(group分析中已经说明，group最大为128M，即2^27 bytes)，那么一个group全部存储groups元数据，才会有2^27 / 64=2^21个，更何况，也无法全部用来存储groups元数据。这样会产生一个限制，以Ext4的块组描述符大小64 Bytes计算，文件系统中最多只能有2^21个块组，也就是文件系统最大为256TB。
使用Meta Block Groups特性，整个文件系统被分成多个元块组集(metablock groups)，每个元块组集都是一簇块组组成(簇的含义：一系列物理地址连续的单元)，组成metablock groups的块组描述符都存放在一个block中。对于block大小为4K的Ext4文件系统，一个元块组包含64个块组，也就是64G的磁盘空间(128M*64=8G)。Meta Block Groups特性将存放在系统第一个块组的元数据分割存放在多个MetaBlock
Groups中。
因为Ext4支持的是48bits block寻址方式，所以最大卷大小为2^48个block，2^48*2^12=2^60B=1EB，而每个group为128M=2^27B，所以有2^60/2^27=2^33个group。
那么为什么是48bits寻址而不是64bits哪，虽然在ext4_super_block中blocks寻址的高位和地位均为32bits：
__le32
s_blocks_count_lo; /* Blocks count */
__le32
s_blocks_count_hi; /* Blocks count */
原因在于：在使得ext4系统完全支持64bits block寻址时，还有一些限制没有解决，但是可以相信的是，在以后某个时候肯定会完全支持64bits，但是我像1EB已经足够。
【There are some limitations that would need to be fixed before making Ext4 fully 64-bit capable, which have not been addressed in Ext4.
The Ext4 data structures have been designed keeping this in mind, so a future update to Ext4 will implement full 64-bit support at some point. 1 EB will be enough (really :)) until that happens. (Note: The code to create filesystems bigger than 16 TB is -at
the time of writing this article- not in any stable release of e2fsprogs. It will be in future releases.)】
Meta Block Groups特性的出现使得Ext3和Ext4的磁盘布局有了一定的变化，以往超级块后紧跟的是变长的GDT块，现在是超级块依然决定于是否是3,5,7的幂，而块组描述符集则存储在元块组的第一个，第二个和最后一个块组的开始处(见下图)
在两种情况下我们可能会用到这种新布局：
(1) 文件系统创建时。用户可以指定使用这种布局。
(2) 当文件系统增长而且预留的组描述符块耗尽时。目前超级块中有一个域s_first_meta_bg用于描述第一个使用元块组的块组。
当增加新块组时，我们不需要给组描述符表预留空间，而是在当前文件系统后面直接添加新的元块组就可以了。