LVM modifying commands' latency normal?

[Ralph Grothe]

Hi,

I'm just curious.
I've got a cluster shared VG whose disks are from an HITACHI Lightning 9900V RAID.
Unfortunately this VGDA has to handle 100 disks because I'm only furnished with 7 GB disk chunks (aka PVs) from the RAID box.

# strings /etc/lvmtab|sed -n '\:/dev/vgZ01:,\:/dev/vg:p'|grep dsk|wc -w
100

Whenever I have to forinstance lvextend an LV this takes annoyingly long.

e.g.

# timex lvextend -l $((128+9565)) /dev/vgZ01/lvol14
Logical volume "/dev/vgZ01/lvol14" has been successfully extended.
Volume Group configuration for /dev/vgZ01 has been saved in /etc/lvmconf/vgZ01.c
onf

real 1:35.23
user 4.85
sys 7.77


Is this owe to the large number of PVs in the VG, and thus normal behaviour?
Have you experienced similar?

Rgds.
Ralph

[Dietmar Konermann · Accepted solution]

Ralph,

the delay depends on the size of the LVM header (i.e. the VGRA) and the number of PVs that are part of the VG. I attached the tool 'lvmcompute' that can be used to calculate the VGRA's size.

Best regards...
Dietmar.

[Gerhard Roets]

Ralph is there not a way to tie them together? To many PV's on a raid device can actually create a bottleneck theoretically.

I know if you look at the HP XP product line there is a product called LUSE. This can be used to tie multiple small LDEVS into bigger LUNS and they can be advertised to ports.

This is not a cure for your problem, but in general it is something to look at.

Regards
Gerhard

[Ralph Grothe]

Dietmar,

thank you for providing the lvmcompute binary.