LVM volume creation and vgchange command are incredibly slow. Throughput is very fast.

[omniview]

All,

I've been wrestling with perplexing LVM behaviors this morning, and before I call HP Support, I wanted to give you fine folks a crack at it.

Platform: Two-node MCSG cluster, HP-UX 11.31 VSE OE on Integrity rx6600 servers

Physical volume is a single 1.25TB LUN on a Promise Vtrak 610f SAN (SCSI3 signaling) connected via 4Gb FC to redundant Brocade 5000 4gb FC switches.

We're using the Agile DSF via the Next Generation Storage Stack.

The volume was provided as overflow storage for some of our long-term archive data, as our HDS9960 (~XP512) is filling up. We never see these symptoms on the HDS SAN.


root@thor:/dev# mkdir vg_board_archive
root@thor:/dev# mknod vg_board_archive/group c 64 0x0a0000


root@thor:/dev# timex vgimport -v -s -N -m /tmp/map.vg_board_archive vg_board_archive
Beginning the import process on Volume Group "vg_board_archive".
vgimport: Physical volume "" could not be added to "/etc/lvmtab" and
therefore was not added to the volume group.
Logical volume "/dev/vg_board_archive/lv_7FEB2009" has been successfully created
with lv number 1.
Logical volume "/dev/vg_board_archive/lv_8AUG2008" has been successfully created
with lv number 2.
vgimport: Volume group "/dev/vg_board_archive" has been successfully created.
Warning: A backup of this volume group may not exist on this machine.
Please remember to take a backup using the vgcfgbackup command after activating the volume group.

real 8:06.61 (8 minutes to vgcreate)
user 0.01
sys 0.09



root@thor:/dev# timex vgchange -a e vg_board_archive
Activated volume group in Exclusive Mode.
Volume group "vg_board_archive" has been successfully changed.

real 1:20.94 (1.5 minutes to activate!)
user 0.00
sys 0.01



root@thor:/dev# timex vgchange -a n vg_board_archive
Deactivated volume group in Exclusive Mode.
Volume group "vg_board_archive" has been successfully changed.

real 0.01 (Instantaneous deactivation)
user 0.00
sys 0.01


I've tried creating the Volume Group using legacy DSFs instead. No change.

Still more confusing, once the volume is activated, all other operations are fast. (mount operations, filesystem operations, throughput, etc.)

I've looked at a number of scsimgr(1m) options and tinkered with the disable_flags attributes with no success.

I'd be glad to hear the thoughts of all. Thanks in advance.

Dave

[Torsten. · Accepted solution]

The very first question to ask would be

- is the storage device supported with hp-ux?
- is the storage device supported 11.31?
- are all settings on the device correct for 11.31?

[Duncan Edmonstone]

well if the HDS is fine, then to be honest I'd be starting a conversation with Promise, not with HP. What evidence do you have that the Promise device is supported with HP-UX? The data sheet at least seems to suggest Windows & Linux only:

http://www.promise.com/upload/datasheet/VTrak-VTE610f_std_112807.pdf

HTH

Duncan

[Torsten.]

What I see on the web is



Supported Operating Systems


Mac OS X, Mac OS X server, versions 10.5.2 and later, Windows 2003, Linux (Red Hat, SuSE)

Can you confirm?

[omniview]

I've not been able to find anything regarding the Promise vTrak SAN and HP-UX at all, one way or the other.

You are all 100% correct. It does seem to imply that this is not an supported hardware configuration.

We were hoping to use this to meet unfunded storage needs.

[Torsten.]

The problem is in simple words, the array must be able to "speak" the right language for hp-ux, e.g. in terms of presentation mode etc... Without a mode setting for hp-ux it ends up with a total mismatch (e.g. you see a device in both, loop and fabric mode) and you will will see very strange things on the server side ...

;-)

[omniview]

You gentlemen make excellent points and definitely answered my question.

Thanks!

[omniview]

The only viable solution is to do some re-arranging on the HDS9960 and to abandon the use of the Promise vTrak.

Thanks again!