On Oct 08, 2002 15:54 +0200, Helge Hafting wrote:
> Andrew Morton wrote:
> > Part of the problem here is that it has got worse over time. The
> > size of a blockgroup is hardwired to blocksize*bits-in-a-byte*blocksize.
> > But disks keep on getting bigger. Five years ago (when, presumably, this
> > algorithm was designed), a typical partition had, what? Maybe four
> > blockgroups? Now it has hundreds, and so the "levelling" is levelling
> > across hundreds of blockgroups and not just a handful.
>
> If having only "a few" block groups really work better
> (even for todays bigger disks) then bigger
> block groups seems like a solution.
>
> changing the on-disk format might not be popular, but there
> is no need for that. Simply regard several on-disk block
> groups as a bigger "allocation group" when using the above
> algorithm. This should be perfectly backwards compatible.
We already have plans for something like this - a "meta blockgroup".
This will help us with several things, actually, so it is likely to
be implemented.
Cheers, Andreas
-- Andreas Dilger http://www-mddsp.enel.ucalgary.ca/People/adilger/ http://sourceforge.net/projects/ext2resize/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:25 EST