From: "Jose R. Santos" <jrs@us.ibm.com>
Subject: [RFC] BIG_BG vs extended META_BG in ext4
Date: Fri, 29 Jun 2007 17:09:58 -0500
Message-ID: <20070629170958.13b7700c@gara>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
To: linux-ext4 <linux-ext4@vger.kernel.org>
Sender: linux-ext4-owner@vger.kernel.org

Hi folks,

I've been looking at getting around some of the limitations imposed by
the block groups and was wondering what are peoples thoughts about
implementing this using either bigger block groups or storing the
bitmaps and inode tables outside of the block groups.  

I think the BIG_BG feature is better suited to the design philosophy of
ext2/3.  Since all the important meta-data is easily accessible thanks
to the static filesystem  layout, I would expect for easier fsck
recovery.  This should also provide with some performance improvements
for both extents (allowing each extent to be larger than 128M) as well
as fsck since bitmaps would be place closer together.

An extended version of metadata block group could provide better
performance improvements during fsck time since we could pack all of
the filesystem bitmaps together.  Having the inode tables separated
from the block groups could mean that we could implement dynamic inodes
in the future as well.  This feature seems like it would be more
invasive for e2fspros at first glance (at least for fsck).  Also, with
no metadata in the block groups, there is essentially no need to have a
concept of block groups anymore which would mean that this is a
completely different filesystem layout compared to ext2/3.

Since I have not much experience with ext4 development, I was wondering
if anybody had any opinion as to which of these two methods would
better serve the need of the intended users and see which one would be
worth to prototype first.

Comments?


-JRS