[CentOS] Disk Elevator

[Ross S. W. Walker]

> -----Original Message-----
> From: centos-bounces at centos.org 
> [mailto:centos-bounces at centos.org] On Behalf Of Ross S. W. Walker
> Sent: Monday, January 08, 2007 1:15 PM
> To: CentOS mailing list
> Subject: RE: [CentOS] Disk Elevator
> 
> > -----Original Message-----
> > From: centos-bounces at centos.org 
> > [mailto:centos-bounces at centos.org] On Behalf Of Aleksandar 
> Milivojevic
> > Sent: Monday, January 08, 2007 1:00 PM
> > To: centos at centos.org
> > Subject: RE: [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?
> 

Let me follow up on my last post by saying that Aleksandar is abolutely
correct. The stride is the # of blocks per-stripe and has nothing to do
with read-ahead, and thus should be calculated by # of chunks minus
parity in a stripe.

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

-Ross



______________________________________________________________________
This e-mail, and any attachments thereto, is intended only for use by
the addressee(s) named herein and may contain legally privileged
and/or confidential information. If you are not the intended recipient
of this e-mail, you are hereby notified that any dissemination,
distribution or copying of this e-mail, and any attachments thereto,
is strictly prohibited. If you have received this e-mail in error,
please immediately notify the sender and permanently delete the
original and any copy or printout thereof.