Re: using non-default blocks per group

["Jeffrey W. Baker" <jwbaker acm org>]

On Fri, 19 Oct 2001, Andreas Dilger wrote:

> On Oct 19, 2001  12:52 -0700, Jeffrey W. Baker wrote:
> > I've been playing with the -g switch to mke2fs, which controls the blocks
> > per group.  This switch isn't documented.  I've been using it to balance
> > metadata traffic on RAID 0.
> >
> > This seems to work fine in ext2.  Will I have any problems with ext3 where
> > the blocks per group is not a power of 2?
>
> This shouldn't cause any problems anywhere.  It may be that some poorly
> coded ext2 tools will use "blocksize*8" as the number of blocks per group,
> but that is just plain wrong (even if it matches 99.9% of the configs out
> there).  Ext3 does nothing (AFAIK) to change the behaviour of this part
> of the code.

Indeed, mke2fs won't use anything but multiples of 8.

> You do know about the "-R stride" option for mke2fs?  It is also supposed
> to help balance bitmap I/O across multiple disks.  It doesn't help with
> inode tables, however, but since they are normally quite large, they should
> be striped across multiple disks anyways.

I have always used the -R stride option but it never works.  I always get
a metadata hotspot.  For example, copying the mozilla source tree
recursively will result in twice as many SCSI commands on the hot disk as
the other disk (in a 2-disk RAID 0).

I posted over on the linux-raid list about this.  I tried a chunk of 128k
and a stride of 8, 16, 32, and 64 with a 4k block and all configurations
had a hot spot.  By changing the blocks per group, traffic was balanced
evenly.

-jwb