[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: using non-default blocks per group



On Oct 19, 2001  15:17 -0700, Jeffrey W. Baker wrote:
> On Fri, 19 Oct 2001, Andreas Dilger wrote:
> > 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.

It definitely needs to be a multiple of 8, just not the maximum, which is
blocksize*8 (maximum number of bits in a single block).

> > 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.

Hmm, I don't think that anything but 32 would produce useful results.  The
reason is that values less than the chunk size will put multiple consecutive
bitmaps on a single disk, while anything larger (even multiple like 64*4kB)
would put them all on the same disk.

Cheers, Andreas
--
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]