linux-ext4 - Re: [RFC] BIG_BG vs extended META

lists.openwall.net		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-next>] [day] [month] [year] [list]

Message-ID: <20070630234011.38b4bb22@gara>
Date:	Sat, 30 Jun 2007 23:40:11 -0500
From:	"Jose R. Santos" <jrs@...ibm.com>
To:	Laurent Vivier <Laurent.Vivier@...l.net>
Cc:	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: [RFC] BIG_BG vs extended META_BG in ext4

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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Le 29 juin 07 à 18:09, Jose R. Santos a écrit :
> 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 ;-)
> 
> BIG_BG allows to limit the number of groups (at least in the group  
> 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 can
be reduce with small block groups.

> For instance, if we keep the same inode table allocation politic, we  
> divide the total number of inode in the FS by the total number of  
> groups.
> For the moment, number of inode < 2^32 and if we have number of block  
> group > 2^32 the number of inode per group is 0.... is META_BG able  
> 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. ;)

> With META_BG, a 2^48 blocks FS will have 2^48 / 2^12 = 2^36 groups.  
> Perhaps it could be interesting to have less groups ?

Agree...

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

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
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html