Staggering LVM stripes

[Steve Massey_1]

Hi

An earlier posting descibed a method of designing a striped set, that had each logical volume starting on a different physical volume.

Is anyone - or the originator able to give the technical low-down as to what and why this has benifits

thanks

Steve

[Andy Monks]

Hi Steve,

Striping the data acss a numer of discs can reduce bottlenecks by allowing the requests to be serviced by multiple disks/controlers. However, if you assume that there are 5 disks in your stripe, striping more that one logical volume may cause performance problems (as it's possible that you'll just hit one disk).

Also, what I've seen (and I had to laugh), was someone using Raid 5 and then using lvm striping across 5 luns on an array. Apparently, it wasn't very quick. They were also using Oracle, which spreads it's data around too, so in effect they were striping 3 times.

The best idea, is to try and benchmark various setups in YOUR environment. What works best on one setup, might be really bad on another.

My rules of thumb, would be :-

1. If your hardware does striping (RAID 5 etc) let it and don't let lvm do it

2. Only use disks in 1 strip set (so only 1 lvol per set of disks)

3. BENCHMARK, BENCHMARK, BENCHMARK!

Andy

[Stefan Farrelly]

On a JFS filesystem the logging is all done on the first part of the lvol, so on a busy system, i/o wise, if you have all your lvols with their first extent on the same disk+channel you are always going to saturate that disk+channel. Thus to avoid this when creating your lvols ensure each starts on a different disk+channel and you will balance the i/o load nicely across your available disks+channels. All HP internal Openmail servers worldwide are built this way.

If you want to test it do some time dd commands and then switch jfs logging between log, delaylog and nolog and you should see a difference - indicating how much i/o jfs logging is doing.

Stefan
HP OSD
ex MCEE