[CentOS] Disk Elevator

> > > Quoting "Ross S. W. Walker" <rwalker at medallion.com>:
> > >
> > > > The biggest performance gain you can achieve on a raid
> > > array is to make
> > > > sure you format the volume aligned to your raid stripe
> > > size. For example
> > > > if you have a 4 drive raid 5 and it is using 64K chunks,
> > your stripe
> > > > size will be 256K. Given a 4K filesystem block size you
> > > would then have
> > > > a stride of 64 (256/4), so when you format your volume:
> > > >
> > > > Mke2fs -E stride=64 (other needed options -j for ext3, -N
> > > <# of inodes>
> > > > for extended # of i-nodes, -O dir_index speeds up directory
> > > searches for
> > > > large # of files) /dev/XXXX
> > >
> > > Shouldn't the argument for stride option be how many file system
> > > blocks there is per stripe?  After all, there's no way for OS
> > > to guess
> > > what RAID level you are using.  For 4 disk RAID5 with 64k
> > chunks and
> > > 4k file system blocks you have only 48 file system blocks
> > per stripe
> > > ((4-1)x64k/4k=48).  So it should be -E stride=48 in this
> > particular
> > > case.  If it was 4 disk RAID0 array, than it would be 64
> > > (4x64k/4k=64).  If it was 4 disk RAID10 array, than it would be 32
> > > ((4/2)*64k/4k=32).  Or at least that's the way I understood it by
> > > reading the man page.
> >
> > You are correct, leave one of the chunks off for the parity, so for 4
> > disk raid5 stride=48. I had just computed all 4 chunks as part of the
> > stride.
> >
> > BTW that parity chunk still needs to be in memory to avoid the read on
> > it, no? In that case wouldn't a stride of 64 help in that case? And if
> > the stride leaves out the parity chunk then will not successive
> > read-aheads cause a continuous wrap of the stripe which will
> > negate the
> > effect of the stride by not having the complete stripe cached?

> For read-ahead, you would set this through blockdev --setra X /dev/YY,
> and use a multiple of the # of sectors in a stripe, so for a 256K
> stripe, set the read-ahead to 512, 1024, 2048, depending if the io is
> mostly random or mostly sequential (bigger for sequential, smaller for
> random).


To follow up on this (even if it is a little late), how is this
affected by LVM use?
I'm curious to know how (or if) this math changes with ext3 sitting on
LVM on the raid array.

-- 
During times of universal deceit, telling the truth becomes a revolutionary act.
George Orwell