topic Re: migrating to new disk in Disk Enclosures

migrating to new disk

Ed McKnight — Fri, 06 Jul 2001 18:37:37 GMT

I have a K260 with hp-ux 11. and 2 3312 jamaca's mirrored.
this started with 1 4gig disk each, the database got too big and the largest filesystem was moved to a new 4gig, again it grows and the largest filesystem is moved to a third 4gig, the first problem file grows and is extended to a 4th 4gig disk. now I arrive, I get 2 18gig disks I want to stripe these as one space and then allocate for the filesystems
first I want to move everything to the 36gig space and then stripe the 4 4gig's into 1 16gig then move some things back. PLEASE what is the most foolproof and least painfull way to do this! cpio, mirror, tape? all the mount points need to keep the orignal names i.e. /uvdata /uvdata2 /uvdata3....
this used to be the production system it is now the development/'failover' system but the production files are bigger than the filesystems. this is the reason to add lots of space. Thanks in advance. Ed

Re: migrating to new disk

Shahul — Sat, 07 Jul 2001 09:21:15 GMT

Hi

I think mirroring is the best option for U.

With rgds, Shahul

Re: migrating to new disk

Jordan Bean — Mon, 09 Jul 2001 05:23:44 GMT

Can you provide a vgdisplay -v and ioscan -fnC disk? I'd like to help you plan everything step by step if necessary.

Assuming all the 4gig disks are in one vg, if "Max PE per PV" is large enough to accommodate the 18gig disks, them mirroring may work well. Otherwise, a new vg will be required and the migration will be more involved.

Re: migrating to new disk

Ed McKnight — Mon, 09 Jul 2001 13:37:19 GMT

I have attached devel.txt it contains the output from vgdisplay -v and ioscan -fnC disk.
Thanks for any help you can give me.
Ed

Re: migrating to new disk

Jordan Bean — Mon, 09 Jul 2001 16:50:02 GMT

What do you want to do with the two 9g disks of vg02? I was expecting to find only eight 4g and four 18g disks evenly distributed between jamaicas, but you also have two 9g disks occupying the same enclosure. I also noticed that this vg is using 32m extents.

Re: migrating to new disk

Ed McKnight — Mon, 09 Jul 2001 18:25:43 GMT

Sorry, the 9gigs are to be removed these are not supported under our hp support contract. They were a stopgap measure to get us past an emergency

Re: migrating to new disk

Jordan Bean — Mon, 09 Jul 2001 23:07:29 GMT

Okay, ignoring the 9g disks.

Since the existing vgs cannot accommodate the full capacity of the 18g disks, I'd go with creating a new bootable vg with all the necessary filesystems and copy the data over with cpio. This would be a good time to determine if you want to resize any logical volumes (like swap). After successfully booting into the new vg, the previous vgs can be obliterated, the new vg renamed to vg00, the physical volumes recreated, and another new vg created to which some data can be moved. This is pretty involved, but the pay-off is a clean configuration... I'll throw together some more notes tonight while I have time...

Re: migrating to new disk

Jordan Bean — Tue, 10 Jul 2001 17:17:11 GMT

I've attached my procedures (far from complete since a few more decisions still need to be made). It looks like a posix-shell script, but it's not.

Re: migrating to new disk

Ed McKnight — Wed, 11 Jul 2001 21:54:29 GMT

I know you said this is not a script but what do i do with the, if then do while fi done, part?
I thank you for your help and I am going over all the commands putting in my numbers and choosing sizes for the file systems.
I am changing the game plan to suit my boss,
the 2x18s will be for the data,
then 2x4s for root/sys files
1x 4 for /tmp
( our database uses var to reindex and some files are more than 1gig)
the last 4 will be held for whatever happens next.
1x 9gig will come out
1x 9gig for junk space/moving stuff/extra copies just in case.

Re: migrating to new disk

Jordan Bean — Thu, 12 Jul 2001 15:44:50 GMT

Sorry, I'm about to contradict myself. Let me completely truthful about this file.

It IS a posix shell script, but I never intended for it to be run. Even if it were complete, accurate, and started first with `set -ex` to exit on error and echo all commands and parameters as they are executed, I still wouldn't run it. I tend to document my procedures as a script because the instructions are exact and cannot be misunderstood. So if you are comfortable with the changes you've made, you can run the script and keep an eye on it while arguing with an end user on the phone about taking up 73% of /home because he or she refuses to delete anything. Since it's a posix shell script, you can (as long as you're in the posix shell) literally execute the if, while, for, until, case, etc blocks interactively.