topic Re: Not enough free physical extents in Operating System - HP-UX

Not enough free physical extents

itrc55 — Wed, 08 Jun 2011 13:01:00 GMT

Hi,

i trying to extend the logical volume but i facing this error

"lvextend: Not enough free physical extents "

i change the lvol policy to not strict how i can solving this issue.

sdh014 #lvextend -L 153600M /dev/appsvg/lv_cmpt-elink
lvextend: Not enough free physical extents available.
Logical volume "/dev/appsvg/lv_cmpt-elink" could not be extended.
sdh014 #
sdh014 #
sdh014 #
sdh014 #
sdh014 #vgdisplay appsvg
--- Volume groups ---
VG Name /dev/appsvg
VG Write Access read/write
VG Status available
Max LV 2047
Cur LV 8
Open LV 8
Cur Snapshot LV 0
Max PV 2048
Cur PV 6
Act PV 6
Max PE per PV 163840
VGDA 12
PE Size (Mbytes) 64
Unshare unit size (Kbytes) 1024
Total PE 7194
Alloc PE 5584
Current pre-allocated PE 0
Free PE 1610
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0
VG Version 2.2
VG Max Size 10t
VG Max Extents 163840
Cur Snapshot Capacity 0p
Max Snapshot Capacity 10t

sdh014 #lvdisplay /dev/appsvg/lv_cmpt-elink
--- Logical volumes ---
LV Name /dev/appsvg/lv_cmpt-elink
VG Name /dev/appsvg
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 10240
Current LE 160
Allocated PE 160
Stripes 0
Stripe Size (Kbytes) 0
Bad block NONE
Allocation non-strict
IO Timeout (Seconds) default
Number of Snapshots 0
Thanks

Re: Not enough free physical extents

itrc55 — Wed, 08 Jun 2011 13:51:41 GMT

Hi,

my OS is 11.31 when i trying to use the vgmodify command with any option i see this message

sdh014 #vgmodify -v -r appsvg
Usage:
For deactivated version 1.0 volume groups,
vgmodify
[-v]
[-n]
[-r]
[-e MaxPhysicalExtents]
[-p MaxPhysicalVolumes]
[-l MaxLogicalVolumes]
VolumeGroupName

vgmodify -B bootable
[-n]
[-r]
[-v]
[-e MaxPhysicalExtents]
[-p MaxPhysicalVolumes]
[-l MaxLogicalVolumes]
VolumeGroupName pv_path...

vgmodify -o
[-v]
[-r]
VolumeGroupName

vgmodify -o -B bootable
[-v]
[-r]
VolumeGroupName pv_path...

vgmodify -C DLC_Size
[-r]
VolumeGroupName pv_path

For activated version 1.0 volume groups,
vgmodify -a
[-v]
[-n]
[-r]
[-e MaxPhysicalExtents]
[-p MaxPhysicalVolumes]
[-l MaxLogicalVolumes]
VolumeGroupName

vgmodify -a -B bootable
[-n]
[-r]
[-v]
[-e MaxPhysicalExtents]
[-p MaxPhysicalVolumes]
[-l MaxLogicalVolumes]
VolumeGroupName pv_path...

vgmodify -a -o
[-v]
[-r]
VolumeGroupName

vgmodify -a -o -B bootable
[-v]
[-r]
VolumeGroupName pv_path...

vgmodify -a -E
[-o]
[-v]
[-r]
VolumeGroupName [pv_path...]

vgmodify -a -E
[-v]
[-r]
[-e MaxPhysicalExtents]
[-p MaxPhysicalVolumes]
[-l MaxLogicalVolumes]
VolumeGroupName [pv_path...]

vgmodify -a -C DLC_Size
[-r]
VolumeGroupName pv_path

To recover a physical volume from a previous online or offline vgmodify failure,
vgmodify -R conf_file VolumeGroupName pv_path ...

To display a table of optimized possible volume group settings for an activated or deactivated version 1.0 volume group,
vgmodify -t
[-v]
[-n]
VolumeGroupName

vgmodify -t -B bootable
[-v]
[-n]
VolumeGroupName pv_path...

For activated volume groups version 2.0 and higher,
vgmodify -a -E
[-r]
VolumeGroupName [pv_path ...]
vgmodify -a -C DLC_Size
[-r]
VolumeGroupName pv_path
vgmodify -a
[-E]
-S Max_VG_Size [-r] VolumeGroupName
"v": Illegal option.

How to i can use this command. and please don't forget answers for first questions.

Thanks

Re: Not enough free physical extents

Duncan Edmonstone — Wed, 08 Jun 2011 14:19:36 GMT

Seems pretty obvious to me...

You have a LV currently assigned with 160 physical extents

You want the new size of the LV to be 153600MB which is 153600 / 64 = 2400 physical extents.

So you want to grow the LV by 2400 -160 = 2240 physical extents.

But you only have 1610 free physical extents in the VG.

So you are trying to grow your LV to a size larger than the free space in the VG.

HTH

Duncan

Re: Not enough free physical extents

Matti_Kurkela — Wed, 08 Jun 2011 14:25:49 GMT

You want to extend the LV to size 153600M. As the extent size 64M, the LV should be extended to 153600M / 64M = 2400 extents.

As there are no mirror copies, 1 logical extent = 1 physical extent.

The LV currently occupies 160 extents. So you'll need 2400 - 160 = 2240 free extents to successfully extend the LV.

Your disk currently has only 1610 free extents, which is not enough. Changing the allocation policy won't help you here: you'll need to add one or more new PVs to this VG.

The "vgmodify" command won't help either: there is simply not enough space in the VG currently to successfully extend to the size you're planning.

Your VG currently has a total of 7194 extents on 6 different PVs. If all the PVs are the same size, your current PVs all have 1199 extents apiece, or 1199 * 64 M = 76736M per PV.

If your new PVs are the same size as your current ones, one more PV will be sufficient. Since MaxPV is 2048, you can add this PV (and many more, if you want!) without using vgmodify.

If you have SAN storage or hot-pluggable local disk slots, plug in a new disk, then run "ioscan -fnCdisk" (or "ioscan -fnNCdisk" in HP-UX 11.31) to see the new disk, then run "insf" to create the device nodes for it.

After the new disk is visible to the system, you can run "pvcreate" on it to make the disk usable for LVM, then "vgextend" to attach it to the appsvg volume group. This will increase the "Total PE" and "Free PE" values in the "vgdisplay appsvg" listing, according to the size of the new PV.

Once the "Free PE" value is 2240 or larger, you can use the "lvextend -L 153600M /dev/appsvg/lv_cmpt-elink" you originally planned.

Without adding any new PVs to the volume group, you can only extend your LV to 1610 + 160 = 1770 extents, or 1770 * 64M = 113280M in size, i.e.

lvextend -L 113280 /dev/appsvg/lv_cmpt-elink

MK

Re: Not enough free physical extents

g3jza — Wed, 08 Jun 2011 14:25:51 GMT

Hi,
for the first question:

in your VG you have only 1610*64=103040MB free.

Your LV now has 10240MB.
You want to increase the LV size to 153600MB, which is impossible.

Re: Not enough free physical extents

itrc55 — Wed, 08 Jun 2011 16:25:02 GMT

Hi,

Thanks for your support, but What about the second question.

Thanks

Re: Not enough free physical extents

g3jza — Wed, 08 Jun 2011 16:32:54 GMT

what are you trying to achieve with the vgmodify command?

Re: Not enough free physical extents

itrc55 — Wed, 08 Jun 2011 19:22:41 GMT

Hi,

what are you trying to achieve with the vgmodify command?

Nothing now but Maybe I need it in the future.

how i can using this command ???

Thanks

Re: Not enough free physical extents

Ismail Azad — Wed, 08 Jun 2011 19:36:36 GMT

HI itrc,

You have left out the volume group name in your syntax.

Random example...

vgmodify -p 15 -l 253 -e 65543 vg01 ....

For the new versions of LVM , the subsystem itself has it's own view of optimizing the LVM attributes for which you see options like -o.

Also the -t option is useful and gives the required parameters in a readable friendly table format.

Regards
Ismail Azad

Re: Not enough free physical extents

Duncan Edmonstone — Tue, 18 May 2021 13:08:44 GMT

There's a whole technical paper on vgmodify here:

http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c01920387/c01920387.pdf

HTH

Duncan

Re: Not enough free physical extents

itrc55 — Thu, 09 Jun 2011 12:43:06 GMT

Hi,

But still I don't understand how to use vgmodify on 11.31.

Thanks

Re: Not enough free physical extents

Matti_Kurkela — Fri, 18 Jun 2021 09:15:45 GMT

> trying to use the vgmodify command with any option i see this message

>sdh014 #vgmodify -v -r appsvg
>Usage:

In other words, vgmodify is trying to tell you that you used a wrong combination of options.

The "Usage:" list is grouped according to various use cases. Each use case has some mandatory options, and some optional options. The optional options are within [brackets].

The very first use case is:
>For deactivated version 1.0 volume groups,
>vgmodify
>[-v]
>[-n]
>[-r]
>[-e MaxPhysicalExtents]
>[-p MaxPhysicalVolumes]
>[-l MaxLogicalVolumes]
>VolumeGroupName
>[...]

This matches the command line you entered. From your question in the original post, it is obvious that the "appsvg" volume group exists.

Note that the use case is for _deactivated_ volume groups of _version 1.0_.

First, since you did not say anything about running "vgchange -a n appsvg" your "appsvg" VG is probably still active, i.e. it is _not_ deactivated.

Second, the "vgdisplay appsvg" output in your original post indicates:

>VG Version 2.2

... so this is _not_ a version 1.0 volume group.

That's two reasons why your command did not work!

For a version 2.2 volume groups, the only applicable use cases are here:

>For activated volume groups version 2.0 and higher,
>vgmodify -a -E
>[-r]
>VolumeGroupName [pv_path ...]

>vgmodify -a -C DLC_Size
>[-r]
>VolumeGroupName pv_path

>vgmodify -a
>[-E]
>-S Max_VG_Size [-r] VolumeGroupName

In other words, to manipulate version 2.0 or higher volume groups at all, the VG must be activated.

Also, there is no -v option for version 2.0 or higher volume groups. (A third version why your command did not work!)

Looking at all the use cases together, the '-a' option is mandatory every time you use vgmodify to manipulate an activated VG.

According to the technical paper linked by Duncan, the options -E and -C are associated with changing the size of already-presented storage LUNs.

So, if your storage administrator expands an existing appsvg LUN instead of giving you an extra LUN for extending your appsvg volume group, you'll need "vgmodify -a -E appsvg" to make LVM see the added space.

Alternatively, if you need to shrink an existing LUN, you must first arrange for enough free space on the PV you wish to shrink (by reducing filesystems or using pvmove to move allocated extents elsewhere), then you can use "vgmodify -a -C appsvg /dev/disk/diskXX" to tell the LVM that the LUN that contains the diskXX PV is about to shrink, and only _after that_ you can tell your storage admin to shrink the LUN.

If the VG maximum size limit (for appsvg, the vgdisplay command in the original post says "VG Max Size 10t") turns out to be too small, then you can use "vgmodify -a -S appsvg" to change it. Your current VG size is 7194 extents * 64 MB/extent = about 460 GB. That is a lot less than the current max size of 10 Terabytes, so you can expand this VG a lot without hitting the maximum size limit.

If you add the "-r" option to any of the above-mentioned command lines, then vgmodify won't actually do the operation: it will only display what the results would be.

The version of vgmodify on your system seems to be more capable than the one on my 11.31 test system: your 11.31 system is apparently newer (or more up-to-date with patches) than my test system currently is.

You should use "man vgmodify": this command will display documentation that has been proofread by HP and should be in sync with the version of vgmodify you actually have.

MK