lvextend / - root file system

[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