HP-UX Logical Volume Manager and MirrorDisk/UX Release Notes HP-UX 11iv3 (August 2011)

Table 1 LVM Fixes in HP-UX 11i v3 August 2011 Web Release (continued)
DescriptionDefect ID
Unique PVID: The contents of the file /etc/lvmconf/pv_lock were
overwritten with same data or the file timestamp on the file
was modified.
Possibly touch or tar -x was performed on the file.
There could be delay or failure in the generation of unique PVIDs.
On an HP-UX 11iv3 September 2009 or later version of HP-UX Recovery shell, vgimport
operation on an LVM volume group (of any VG version) with one or more mirrored logical
volume fails with the following error message:
QXCR1001100445
The volume group contains a mirrored logical volume(s).
MirrorDisk/UX should be installed in order to import the
volume group containing mirrored logical volumes.
The lvcreate command allocates one extent in the physical volume group which has one
physical volume and the remaining extents in the next physical volume group when the logical
volume has distributed pvg-strict policy.
QXCR1001101479
There is a small performance penalty when VxFS 5.0.1 is used on a LVM logical volume since
LVM unnecessarily restricts async I/Os to 256KB.
QXCR1001101905
The lvextend command allocates one extent in the physical volume group which has one
physical volume and the remaining extents in the next physical volume group when the logical
volume has distributed pvg-strict policy.
QXCR1001110394
In a LVM shared volume group, if both internal resync (triggered by a physical volume
coming back online) and I/Os are targeted for the same extents (in any of the nodes), it may
lead to IOs hang when there is heavy I/O load and frequent intermittent disk failures.
QXCR1001110492
When run on a version 1.0 volume group, vgmodify -a coredumps or complains:QXCR1001112083
Physical Volume PV_name entry in new VGDA incorrect.
While creating a distributed PVG-Strict logical volume on a 1.0 volume group, LVM allocates
one extent in the physical volume group which has only one physical volume and the remaining
QXCR1001119089
extents in the next physical volume group that has more than one disk. Ideally, no extents
should have been allocated in the first PVG group in this case.
Deactivating a shared volume group in the client when the server has crashed would result
in client panic with the following stack trace:
QXCR1001131097
1
panic: slvmp: process bad reply, unknown reply
Stack Trace:
IP Function Name
0xe00000013121c120 slvmp_process_bad_reply+0x280
0xe000000000ee19f0 invoke_callouts_for_self+0x460
0xe000000000ec6070 soft_intr_handler+0x1c0
0xe000000000eed820 external_interrupt+0x4b0
0xe000000001e66780 bubbledown+0x0
0xe000000000e9cba1 idle+0x7b1
End of Stack Trace
User I/Os and mirror resync IOs to a logical volume that is MWC enabled hang when there
are intermittent disk failures under heavy IO load.
QXCR1001134963
1
After the migration of the volume group from version 1.0 to 2.x using vgversion, the
subsequent volume group activation fails with following error message:
QXCR1001135515
1
Couldn't activate volume group vgname
On disk, LVM metadata structures are corrupted.
The pvdisplay command on cluster DSF’s shows the following PV attributes as 'unavailable':QXCR1001137363
1
Data_Start
Data_End
Bootable
In a 3 node cluster, the deactivation of a shared volume group in the server fails if any server
crash happened earlier followed by a deactivation of a volume group on the other client.
QXCR1001145030
1
6 Logical Volume Manager and MirrorDisk/UX Release Notes