Can't lvextend

[Terrence]

I'm trying to lvextend a logical volume after adding disk to the volume group, and I get the following error:

#lvextend -L 38000 /dev/data/u01
lvextend: Not enough free physical extents available.
Logical volume "/dev/data/u01" could not be extended.
lvextend: Couldn't retrieve the list of the physical volumes
belonging to volume group "/dev/data".
Failure possibly caused by strict allocation policy

The volume group is in a service guard cluster, and the disk is a dual pathed raid five 3 disk lun from an FC60.

Here are the exact commands I used after binding the lun and identifying the device files.

pvcreate /dev/rdsk/c6t0d7
vgextend /dev/data /dev/dsk/c6t0d7 /dev/dsk/c4t0d7
(The second disk device file is just the alternative path.)
Then the lvextend you see above. I also updated the other node with the map file from this node.

Here is the output from vgdisplay:

VG Name /dev/data
VG Write Access read/write
VG Status available, exclusive
Max LV 255
Cur LV 3
Open LV 3
Max PV 16
Cur PV 3
Act PV 3
Max PE per PV 20000
VGDA 6
PE Size (Mbytes) 4
Total PE 25983
Alloc PE 17000
Free PE 8983
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

lvmtab looks correct.

Anyone have any ideas?

[Peter Godron]

Hi,
please see:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=970781
and
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=16691

[Terrence]

There is no mirroring going on here. Why would I mirror a raid 5 lun?

I already searched the forum for answers, and I think the difference here is the the line:
lvextend: Couldn't retrieve the list of the physical volumes

Strict allocation and mirroring just shouldn't be an issue here.

I'm wondering if something is corrupt.

[Jeff_Traigle]

You're trying to increase the LV by 38000MB, but you only have 35932MB free ( PE Size (Mbytes) 4 X Free PE 8983).

[Steven E. Protter · Accepted solution]

Shalom,

Most common cause is that the logical volume was set up with strict allocation requiring contiguous allocation.

Clearly you have plenty of rree PE's.

lvchange -C n

Try lvextend again.

Failure possibly caused by strict allocation policy

For other possibilities run lvchange without options and see the other possible causes.

SEP

[Terrence]

The logical volume is already 28 GB so I'm actually only increasing it by 10 GB.

[Terrence]

Shalom Steven,

How do I check to see if it is setup to be contiguous?

is it safe to make that lvchanged in a live service guard cluster?

What about could retrieve list of the physical volumes? I've never seen that before.

[Joseph C. Denman]

You gave away the rabbit too soon! Could you post the output from vgdisplay -v data

...jcd...

[Terrence]

Not sure what you mean by rabbit.

#vgdisplay -v data
--- Volume groups ---
VG Name /dev/data
VG Write Access read/write
VG Status available, exclusive
Max LV 255
Cur LV 3
Open LV 3
Max PV 16
Cur PV 3
Act PV 3
Max PE per PV 20000
VGDA 6
PE Size (Mbytes) 4
Total PE 25983
Alloc PE 17000
Free PE 8983
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

--- Logical volumes ---
LV Name /dev/data/u01
LV Status available/syncd
LV Size (Mbytes) 28000
Current LE 7000
Allocated PE 7000
Used PV 2

LV Name /dev/data/u02
LV Status available/syncd
LV Size (Mbytes) 28000
Current LE 7000
Allocated PE 7000
Used PV 2

LV Name /dev/data/data8
LV Status available/syncd
LV Size (Mbytes) 12000
Current LE 3000
Allocated PE 3000
Used PV 2


--- Physical volumes ---
PV Name /dev/dsk/c4t0d0
PV Name /dev/dsk/c6t0d0 Alternate Link
PV Status available
Total PE 8661
Free PE 161
Autoswitch On

PV Name /dev/dsk/c6t0d1
PV Name /dev/dsk/c4t0d1 Alternate Link
PV Status available
Total PE 8661
Free PE 161
Autoswitch On

PV Name /dev/dsk/c6t0d7
PV Name /dev/dsk/c4t0d7 Alternate Link
PV Status available
Total PE 8661
Free PE 8661
Autoswitch On

[Patrick Wallek]

An lvdisplay for the effected LV would be handy as well.

Check the "Allocation" line in the lvdisplay output. If you see strict/contiguous then that could be your problem. Changing that should be fairly safe to do online via the lvchange command.

[Terrence]

It doesn't say contiguous.

#lvdisplay -v /dev/data/u01 |more
--- Logical volumes ---
LV Name /dev/data/u01
VG Name /dev/data
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule striped
LV Size (Mbytes) 28000
Current LE 7000
Allocated PE 7000
Stripes 2
Stripe Size (Kbytes) 4
Bad block on
Allocation strict
IO Timeout (Seconds) default

--- Distribution of logical volume ---
PV Name LE on PV PE on PV
/dev/dsk/c4t0d0 3500 3500
/dev/dsk/c6t0d1 3500 3500

[Joseph C. Denman]

I'm not sure of the problem????? Someone can help you but, The rabbit comment:::

When you assign more than 7 points to a post, a rabbit shows up on the post. Most forum users will think the issue has been resolved. You probably want to start a new post and paste the info from this one into it.

...jcd...

[Steven E. Protter]

Shalom,

lvdisplay will show you.

It says allocation strict.

Which probably means my lvchange command will work.

Try it, it can't hurt anything.

SEP

[Joseph C. Denman]

YEP, Steven is correct. Check out your allocation line.

...jcd...

[Patrick Wallek]

I think that is incorrect. I don't think strict has anything to do with this.

If you look at the man page for lvcreate you will see that '-S y', which is the default, really only affects mirrors. To summarize the man page: "Mirrors of a logical extent cannot share the same physical volume." So since this is not mirrored the strict allocation policy really has no effect.

You could try doing an 'lvchange -S n /dev/data/u01' but I don't think it would help.

I think the basis of the error is the "Couldn't retrieve the list of the physical volumes...."

I'm not sure why that is coming up especially when vgdisplay looks OK and you said /etc/lvmtab looks OK. If you have a support contract it may be time to involve HP as well.

[Terrence]

lvchange did not solve the issue. Here is my lvmtab:

#strings /etc/lvmtab
/dev/vg00
/dev/dsk/c1t2d0
/dev/dsk/c2t2d0
/dev/data
/dev/dsk/c4t0d0
/dev/dsk/c6t0d1
/dev/dsk/c4t0d1
/dev/dsk/c6t0d0
/dev/dsk/c6t0d7
/dev/dsk/c4t0d7

I will open a call with HP. Sigh