Exploiting new space

[Brendan Newport_2]

I have an idea I know the answer to this, but if there are any alternatives I would be very grateful.

I have a volume group on an 11.23 RX4640 with a single large LUN presented to it from a NetApps filer (1.6TB.) PE Size was set to 32MB and the max PE is 51204 and the total PE is presently 51197, leaving just one extent unallocated at 32MB

I want to exploit the new space, and using the patched vgmodify, tried to modify max_pe, but hit the snag in that the first extent has to be made free;

vgmodify -e 65535 -r /dev/

Current Volume Group settings:
Max LV 255
Max PV 16
Max PE per PV 51204
PE Size (Mbytes) 32
VGRA Size (Kbytes) 6672
vgmodify: This operation can only be completed if PE number zero on "/dev/rdsk/c11t0d5" is freed
vgmodify: Physical Extent renumbering (-n) required to accomplish task

Trying pvmove pointed me to check with pvdisplay and at that point I found extent zero (0000) was employed in a contiguous LV;

pvmove /dev/dsk/c11t0d5:0 /dev/dsk/c11t0d5
The given extent belongs to a contiguous Logical Volume.
This move is not supported. Complete Logical Volume can be moved using -n flag

The options seem a little thin; I think I can only;

1. Have another LUN presented to the VG and pvmove the LV to it, and then run the vgmodify routine to increase max_pe.

or

2. backup the LV's contents, scrag the VG, rebuild it, with PE size at say 64MB and restore the data to the subsequently built LV.

If there is another getout method I would be very grateful to be told it.

Ta!

Bren

[TTr]

I have done option 1. Depends how you want to maneuver the original PV, you only need to add a tiny PV as small as one or two extends. Then you move PE0 from the old PV to the new small PV, change the max_pe and then renumber the PVs. I have done this a few times and did not have any problems but it is a good idea to run a full backup of your PV data before you start.
If you don't have this doc, take a look at it
http://docs.hp.com/en/vgmodify/vgmodify_wp_modified_final.pdf

[TTr]

> leaving just one extent unallocated at 32MB
If I understand correctly this is on the same PV? Then
1. move extend 0 with the vgmodify command
2. change the max_pe
3. Do extend renumbering

[Brendan Newport_2]

Hi!

PE 00000 is showing;

00000 current /dev// 00000


The last extent is free;

51196 free 00000

I clear with;

2. change the max_pe
3. Do extend renumbering

But stuck with "1. move extend 0 with the vgmodify command" as I used the pvmove routine that provoked the contiguous LV error.

Can you detail your solution more explicitely?

Thanks

[Patrick Wallek · Accepted solution]

Try setting the LV so that it is not contiguous.

# lvchange -C n /dev/vg/lv
NOTE: That is an upper-case C and not a lower case c.

# man lvchange
for more information.

[Brendan Newport_2]

Taking the contigurous flag did the trick;

After unmounting the file systems;

lvchange -C n /dev//

then move extent zero to any free extent for a larger VGRA mapping area;

pvmove /dev/dsk/c11t0d5:0 /dev/dsk/c11t0d5
Transferring logical extents of logical volume "/dev//"...
Physical volume "/dev/dsk/c11t0d5" has been successfully moved.

Then deactivate the VG and use vgmodify, in this case dropping the max PV and upping the max pe to get the best combination to exploit the new space;

vgmodify -e 65535 -p 12 /dev/

Reactivate the VG.

Then lvextend to suit the new space (or all of it if required.)

Extend the LV with extendfs.