From: "Jose R. Santos" <jrs@us.ibm.com>
Subject: Re: [RFC] BIG_BG vs extended META_BG in ext4
Date: Sat, 30 Jun 2007 23:40:11 -0500
Message-ID: <20070630234011.38b4bb22@gara>
References: <20070629170958.13b7700c@gara>
	<D5D3223C-4EB0-413B-A81A-05F6DDC0FEEB@bull.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: linux-ext4 <linux-ext4@vger.kernel.org>
To: Laurent Vivier <Laurent.Vivier@bull.net>
In-Reply-To: <D5D3223C-4EB0-413B-A81A-05F6DDC0FEEB@bull.net>
Sender: linux-ext4-owner@vger.kernel.org

On Sat, 30 Jun 2007 11:06:16 -0400
Laurent Vivier <Laurent.Vivier@bull.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>=20
> Le 29 juin 07 =C3=A0 18:09, Jose R. Santos a =C3=A9crit :
> Hi Jose,

Hi Laurent,

Seems like your emails are not making it to the mailing list.  I got
them fine though.

> Thank you for the question ;-)
>=20
> BIG_BG allows to limit the number of groups (at least in the group =20
> counter).
> IMHO, I think it could be important in some cases.

Yes, I think bigger block groups will benefit extents a great deal
since not only can we have larger extents, but I believe that as the
filesystem ages the chances of getting large number contiguous block ca=
n
be reduce with small block groups.
=20
> For instance, if we keep the same inode table allocation politic, we =
=20
> divide the total number of inode in the FS by the total number of =20
> groups.
> For the moment, number of inode < 2^32 and if we have number of block=
 =20
> group > 2^32 the number of inode per group is 0.... is META_BG able =20
> to manage this case ?

Good point.  It is a scenario that needs to be looked, although I
sincerely hope that we get 64-bit inodes implemented by the time
storage devices get that big. ;)
=20
> With META_BG, a 2^48 blocks FS will have 2^48 / 2^12 =3D 2^36 groups.=
 =20
> Perhaps it could be interesting to have less groups ?

Agree...
=20
> With less groups, we load less group descriptors in memory, we have =20
> less I/O to read bitmap and inode array (because we manage less group=
 =20
> descriptors again, because we load bigger bitmap and array in one tim=
e)

Presumably, we would still need to access the same amount data but
latencies should be reduce since we could do larger IO's and less seeks
to read the bitmaps.  I also wonder if there are benefits in terms of
locality to having the bitmaps closer to its blocks vs having them far
away like in xMETA_BG.

> Regards,
> Laurent

-JRS