lvextend / - root file system

[Robert Bennett_3]

I was getting errors when trying to reply to bachphan's thread - so I thought I'd start this one in hopes of helping.

I just had to come up with a way to do this the other day - and it worked! Check these steps out.

1. bdf - note the lvol that / is mounted on (normally /dev/vg00/lvol3)
note the next mount point that is mounted on the next lvol (ex. /tmp - lvol4)

2. vgdisplay -v vg00 - note the number of lvol's and the physical volumes of vg00.

ex. 8 lvol's

--- Physical volumes ---
PV Name /dev/dsk/c0t5d0
PV Status available
Total PE 2169
Free PE 447
Autoswitch On

PV Name /dev/dsk/c0t8d0
PV Status available
Total PE 2169
Free PE 447
Autoswitch On

3. Remove the mirrors off the second physical volume.

for i in 1 2 3 4 5 6 7 8
do
lvreduce -m 0 /dev/vg00/lvol$i /dev/dsk/c0t8d0
done

4. Move the next contiguous lvol from primary OS disk to "mirror" disk

pvmove -n /dev/vg00/lvol4 /dev/dsk/c0t5d0 /dev/dsk/c0t8d0

5. Ensure that you have freed up the logical extents after the / lvol. (ex. lvol3 )

pvdisplay -v /dev/dsk/c0t5d0 | more

01563 current /dev/vg00/lvol3 00020
01564 current /dev/vg00/lvol3 00021
01565 current /dev/vg00/lvol3 00022
01566 current /dev/vg00/lvol3 00023
01567 current /dev/vg00/lvol3 00024
01568 free 00000
01569 free 00000
01570 free 00000
01571 free 00000
01572 free 00000
01573 free 00000
01574 free 00000
01575 free 00000

6. Ensure that the / lvol is strict and contiguous.

lvdisplay /dev/vg00/lvol3

--- Logical volumes ---
LV Name /dev/vg00/lvol3
VG Name /dev/vg00
LV Permission read/write
LV Status available/syncd
Mirror copies 1
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 200
Current LE 50
Allocated PE 110
Stripes 0
Stripe Size (Kbytes) 0
Bad block off
Allocation strict/contiguous
IO Timeout (Seconds) default

7. lvextend the / filesystem to the desired size as needed as long as there are enough free extents available.

lvextend -l 55 /dev/vg00/lvol3
fsadm -F vxfs -b 220M /

8. Move the previously moved lvol back from the mirrored disk to the primary disk.

pvmove -n /dev/vg00/lvol4 /dev/dsk/c0t8d0 /dev/dsk/c0t5d0

9. vgdisplay -v vg00 - ensure that everything is mounted on the primary OS disk and that the mirror disk is empty

--- Physical volumes ---
PV Name /dev/dsk/c0t5d0
PV Status available
Total PE 2169
Free PE 447
Autoswitch On

PV Name /dev/dsk/c0t8d0
PV Status available
Total PE 2169
Free PE 2169
Autoswitch On

10. Mirror all the lvol's back to the mirrored disk.

for i in 1 2 3 4 5 6 7 8
do
lvextend -m 1 /dev/dsk/lvol$i /dev/dsk/c0t8d0
done

11. vgdisplay -v vg00 - ensure that all lvol’s are mirrored.

--- Physical volumes ---
PV Name /dev/dsk/c0t5d0
PV Status available
Total PE 2169
Free PE 447
Autoswitch On

PV Name /dev/dsk/c0t8d0
PV Status available
Total PE 2169
Free PE 447
Autoswitch On

[Devesh Pant_1]

This is an excellent solution Robert,
I wish there was a way to award points to the author of the question.
good job
DP

[Robert Bennett_3]

Thanks -

Acknowledgement from my peers is good enough for me. ;-}

[generic_1]

/opt/ignite/bin/make_tape_recovery -a /dev/rmt/0mn -I -v -x inc_entire=vg00

Boot to Tape
Choose new size for filesystems
Install OS

Remirror Root

Be Happy you just saved allot of time :).

[Devender Khatana]

Robert,

In relation to the corresponding thread the only problem in implementing this solution was that there the disk did not had any free extents, which was required as you need to adjust back the moved LVOL within the same disk without resizing. So it requires atleast one file system to be reduced prior to moving back the LVOL back to this disk.

HTH,
Devender

[D Block 2]

Robert,

very cool,

what does Mirror Copies of 1 imply after
reducing the mirrors?


your step 6 here:
6. Ensure that the / lvol is strict and contiguous.

lvdisplay /dev/vg00/lvol3

--- Logical volumes ---
LV Name /dev/vg00/lvol3
VG Name /dev/vg00
LV Permission read/write
LV Status available/syncd
Mirror copies 1 <--- '1' ?

[Adisuria Wangsadinata_1]

Hi Robert,

The steps will be work, but these steps is not supported by HP. So if there's a problem during extend the root (/) file system, it will get worse.

My recommendation is to use Ignite/UX to solve the problem, for more details about Ignite/UX check the url below :

http://www.docs.hp.com/en/IUX/

Hope this information can help you.

Cheers,
AW

[Kirby A. Joss · Accepted solution]

*** Warning ***
I've done essentially the same procedure, which worked great while running. IIRC we had problems on the subsequent reboot which probably could have been avoided by:

#lvlnboot -R

Unfortunately, I wasn't present at the reboot and my co-worker doesn't recall all the incantations prescribed by HP Response Center when the system didn't want to come back up.

[Robert Bennett_3]

Thanks for all the feedback.

The mirror copy of 1 is just that - the lvol's are mirrored to begin with, nothing more.

Thanks for the heads up on the reboot. I have not rebooted this box yet - I was tasked with extending / without having to reboot - so that's what I did. Luckily I did this to a test box ( an old D350) so I will research the lvlnboot -R command and apply as needed and reboot.

I'll report my findings.

PS - I was on vacation for a week and was pleasantly surprised by the respones.

[Robert Bennett_3]

I ran lvlnboot -R /dev/vg00

then I rebooted - long 8 minutes - but everythings up and running fine, no problems.

I'm not sure I needed to run the lvlnboot -R , as the man page says that starting with HP-UX Release 10.0, this is done automatically.

Better safe than sorry though ;-}

If anyone has a test box that they can play with - give this a shot - it worked for me.

BTW - the reason we had to extend / was because of our /etc/lvmconf - so many volume groups and actually had to remove the .old's as a bandaid solution until we could extend /.

[Florian Heigl (new acc)]

At our site the /etc/lvmconf directorys also grow over our heads after a new standard defined -s 256 -e 65535 -p 255 or something along those lines.

two things (one will make Your neck hair stand up!)

- we went down to -s 256 -e 5000 -p 35 and feel this is really sufficient
- I was helping out at a friend's site when I noticed they had /etc/lvmconf as a lvol of it's own! to my great surprise it really works, even though I couldn't try booting to hpux -lm.
(it was suggested by their HP onsite consultant, they said. but...)

[Charles Holland]

Robert,

We were very interested in your procedure, beliving that make recovery was the ONLY process to extend /. Now it may be the only SUPPORTED way but it truly is an interesting approach.

What we are asuming is that you have online JFS as part of your software package.

We attempted your procedure, in part as our sandbox machine doesn't have mirroring, with a non vg00 lvol.

We were able to get the extendfs to be accepted, could not understand the fsadm command as ours doesn't have the "-b 220M" options so we tried extendfs and it of course said that the lvol had to be unmounted before it would extend the file system.

Is the assumption correct that you do have OLJFS running.

Thanks for a reply.

regards

[Alain Tesserot]

In order to user fsadm on a mounted file system you would need to have online jfs installed and working.

[Robert Bennett_3]

Correct - we have onlineJFS -

Sorry - but I've been out of touch fo a while and just saw that there were more replies to this.

I have done this to a few of our servers now and am confident in this procedure - have at it!

[TwoProc]

I like it Robert - the approach is aimed at getting the space from the next lvol (lvol4 in this case) on the drive for the root lvol (lvol3).

Which makes me wonder - should one consider migrating root to be the LAST lvol on the disk instead of the third? Then all the headroom would ever want to extend root would be available.

Create a new lvol in vg00
dd lvol3 to the new lvol
fix everything up with lvlnboot
fix the /etc/fstab

Reboot .

Wouldn't that work ?

[Patrick Wallek]

LVOL1, 2 and 3 (/stand, pri swap and /) have to be the first on the disk I believe. Not only must they be defined with contiguous extents, but I believe they have to be contiguous to each other as well.

If you move / to be the last LV in /, I think you would break your machine and render it unbootable.

[Robert Bennett_3]

Interesting thoughts.

I'd have to experiment and more so - have time to experiment with that one. But, in the mean time, try this procedure should you need need to extend /.

[TwoProc]

You're probably right Patrick - but the thought came from re-examining the output from lvlnboot:

Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Group:
/dev/dsk/c0t4d0 (8/4.4.0) -- Boot Disk
/dev/dsk/c0t5d0 (8/4.5.0) -- Boot Disk
Boot: lvol1 on: /dev/dsk/c0t4d0
/dev/dsk/c0t5d0
Root: lvol4 on: /dev/dsk/c0t4d0
/dev/dsk/c0t5d0

I can see that boot is on lvol1, and root is on lvol4. Looks highly movable from here. I can/could imagine the concept that "Boot:" may not be movable (just seems that it wouldn't be b/c the boot segment would practically require a static place to look to come up at) - but that "Root:" just might be movable - in that goofy, "just maybe" sense.

I'm not sure I'm SOOO curious/bored that I'm determined to tear up a test server to find out, but at least I've had to convince myself not to b/c of other pressing things! :-)

[D Block 2]

Ok, I'll assume the free-extents all range in sequence, but maybe some-day they don't.

here's your comments:

lvextend the / filesystem to the desired size as needed as long as there are enough free extents available.

lvextend -l 55 /dev/vg00/lvol3
fsadm -F vxfs -b 220M /

What might be a real test, Robert, is running IGNITE and see if you can Recover the file-systems that require the Contiguous Extents ;-)

[Marty Gardner]

Robert, thanks for the solution! I had a very simliar solution but with more steps, (wasn't using "pvmove". What makes this oh-so slick is that you don't have to bring the system down to single user mode! I agree that Make_Net_Recovery is the "preferred" method for resizing "root", but in a "high availability" world, that's not always an option!
Thank you again for the post...

Marty Gardner
UNIX Sys.Admin.
NYS Office of Mental Health
Albany, NY. 12229