[CentOS] Disk Elevator

Tue Jan 16 16:55:22 UTC 2007
Peter Kjellstrom <cap at nsc.liu.se>

On Tuesday 16 January 2007 16:37, Ross S. W. Walker wrote:
...
> > 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.
>
> Depends is the best answer. It really depends on LVM and the other block
> layer devices. As the io requests descend down the different layers they
> will enter multiple request_queues, each request_queue will have and io
> scheduler assigned to it, either the system default or one of the
> others, or one of the block devices own, so it is hard to say. Only by
> testing can you know for sure. In my tests LVM is very good with
> unnoticeable overhead going to hardware RAID, but if you use MD RAID
> then your experience might be different.

I don't think that is quite correct. AFAICT only the "real" devices (such 
as /dev/sda) has an io-scheduler. See the difference of ls /sys/block/..:
 # ls /sys/block/dm-0
 dev  range  removable  size  stat
 # ls /sys/block/sdc
 dev  device  queue  range  removable  size  stat

As for read-ahead it's the reverse. Read-ahead has no effect (in my tests) 
when applied to the underlying device (such as sda) but has to be set on the 
lvm-device. Here are some performance numbers:

sdc:256,dm-0:256 and sdc:8192,dm-0:256 gives:
 # time dd if=file10G of=/dev/null bs=1M
 real    0m59.465s

sdc:8192,dm-0:256 and sdc:8192,dm-0:8192 gives:
 # time dd if=file10G of=/dev/null bs=1M
 real    0m24.163s

This on a 8 disk 3ware raid6 (hardware raid) with fully updated centos-4.4 
x86_64. The file dd read was 1000 MiB. 256 is the default read-ahead and 
blockdev --setra was used to change it.

/Peter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.centos.org/pipermail/centos/attachments/20070116/a4282eff/attachment-0005.sig>