vgcreate hangs

[tommy_28]

Hello,

In hpux 11.23 when I use SAM or vgcreate creating a new VG containing one disk the system hangs there and cannot finish. No message come out from this session screen or other syslog.

From other session I tried vgdisplay or something else I got Cannot lock "/etc/lvmconf//lvm_lock" still trying ..............

I tried rebooted and using another SCSI disk with the another SCSI path, nothing changed.

Really strange. Any solutions?

Thx.
Tommy

[Sunil Sharma_1]

Hi,

I think some other LVM command like lvsync or vgsync is running on same VG.

Please look at this thread for more info..

http://forums1.itrc.hp.com/service/forums/bizsupport/parseCurl.do?CURL=%2Fcm%2FQuestionAnswer%2F1%2C%2C0xf7687bb04b5cd611abdb0090277a778c%2C00.html&forumId=2&admit=716493758+1073370666010+28353475

Sunil

[Sanjay Kumar Suri]

I could recall following steps:

Steps
1. Use ioscan to find device file name for the new disk: #ioscan -funC Disk
2. May initialize the disk: #mediainit -v /dev/rdsk/c0t3d0
3. Use pvcreate command to create LVM data structures needed by LVM to begin using the disk as a physical volume. If the disk was previously part of another group, you may need to use the -f option on pvcreate:

#pvcreate -f /dev/rdsk/c0t3d0

The disk is now ready to be added to a new or existing volume group.

4. Create a directory /dev/vgnn for the volume group.

5. Create control file /dev/vgnn/group. This file provides the means by which LVM kernel and LVM commands communicate within the volume group.

#mknod /dev/vg01/group 64 0x010000 Where 64 is major number (Always). 0x010000 is minor number (Always ends in 0000). hh is the hexadecimal representation of the volume group number. The group files should be owner by root, with rw-r----- permissions.

6. Create the volume group and specify the physical volumes it will contain. You can assign several volumes to a group at one time. #vgcreate /dev/vg01

sks

[Dietmar Konermann]

Thommy,

obviously one of the LVM commands SAM is using hangs while holding a lock on the lvm_lock file.

Check with fuser(1M) what process has that file open. Is it a vgcreate? Or a pvcreate?

# fuser /etc/lvmconf/lvm_lock

What worries me is the fact that you see the same problem with other disks on other paths also. Hardware problems seem to be ruled out though. But what about the root VG? Do you see messages in dmesg/syslog.log?

In the case that vgcreate hangs.... what VG parameters are you using and how long do you wait? The VGRA on disk can get quite large if you choose certain combinations of paramters... so the vgcreate and the following vgcfgbackup could take really long.

Best regards...
Dietmar.

[John Wood_4]

I have a customer with the same problem of vgcreate hanging on 11.23:

# fuser /etc/lvmconf/lvm_lock
/etc/lvmconf/lvm_lock: 25048

# ps -fp 25048
UID PID PPID C STIME TTY TIME COMMAND
root 25048 25047 0 Dec 29 pts/0 0:00 /sbin/vgcreate -e 35004 -l
255 -p 16 -s 4 /dev/vgdata /dev/dsk/

The customer has tried rebooting but this doesn't resolve the problem. Any suggestions?

Thanks,
John

[Dietmar Konermann]

John,

I just found that there's a known problem (JAGae89066) that may cause a vgcreate command to hang on 11.23, if the VGRA gets larger than a single physical extent (error code path!).

A simple workaround for this problem is to choose a larger extent size using the -s option of vgcreate.

The 1st LVM kernel patch for 11.23 is shuld include a fix for this defect.

Best regards...
Dietmar.

[Todd McDaniel_1]

Dietmar,

Is there a paper we can download on that known problem?

[Dietmar Konermann]

Todd,

Looks like JAGae89066 is only internally viewable... so I'm afraid the answer is currently 'no'.

Please note that the problem is only in the error handling code path. Instead of hanging the vgcreate command should print the well known "File too large" error.

Best regards...
Dietmar.

[John Wood_4]

Just to say that my customer rebooted (to get rid of the hung vgcreate) and then re-tried vgcreate but with "-s 32" to specify a 32 MB physical extent, and it worked fine.

Thanks,
John