Originally posted by: SystemAdmin

I have a p520 aix5.2 using storage from a ds4300. Aix sees 2 disks, one is in one lv and the other is in another lv and they are mirrored and when I look at iostat and nmon results it shows that most of time the first copy has all of the reads. The I/Os are not split between the disks evenly, or even close to evenly. The scheduling policy is parallel. Does this happen because the ds4300 makes it look like the disk is almost always available? If not why does it happen and how would we improve this situation?

Originally posted by: SystemAdmin

That is exactly what I have observed some time ago, running tests with internal scsi disks. I used sequential reads/writes.

I learned that both mirrored disks were used for writing with "parallel" policy but only one for reading.

Both disks were used for both reading and writing with "parallel/round robin" policy, but overall read throughput was even less than with "parallel".

IBM sheds some light on the internals of LVM scheduling policies on http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/sched_policy_read_write_log_part_copies.htm

My conclusion was, that "parallel" serves me best for sequential read/write.

Joachim Gann

Originally posted by: nagger

The second copy is only read if the first was actually busy when the read request is made. If the first is not busy it is always used and makes no performance difference. Typically the second starts getting used for read when the first disk gets above ~66% busy. Using the first one most of the time also helps with caches.

This makes sense and also makes sure one disk gets a lot more use than the other.
This is a good thing. The first disk is much more likely to fail due to wear and tear before the second - which is relatively unused. This is VERY GOOD as it let you replace the duff disk with a lower risk of the surviving disk failing too.

Hope this helps, N

Originally posted by: SystemAdmin

Thank you guys! The original documentation I found didn't have the different parallel options. And it makes sense about reading from the first copy mostly and caching.