SUMMARY on reconfiguring the root disk

From: Maw Maw Oo (mimawmao@rba.com.bn)
Date: Thu Apr 29 1999 - 23:07:56 CDT


Dear SUN Managers,

All advice are valuable - advice from Arthur and Ganeshan are particularly useful for what we did.
We managed to reconfigured the /var on the root disk.
Thanks for all prompt responses and thanks for creating this mail server.

My original email is -

> Dear SUN Manager,
>
> After reading the summary about moving /var, I think you may have some
> idea/solution about our problem.
>
> Problem is - we need to reconfigure/repartition the root disk for the SUN
> Solaris 2.6 on which Oracle db and Oracle Financial are running. The
> reason is Oracle Financial need more space for temporary files on /var
> directory. At most only 8 to 10 users can access to financial or db
> currently. If more users try to access them - they're freezed and finally
> hung.
>
> My question is - is it safe enough to repartition the root disk (or
> moving the /var within the same disk) without interrupting the other disks
> where oracle db and financial files are stored. I also attached the
> partition information for the root disk. and df output for the all filing
> systems mounting on the server.
>
>
> # prtvtoc /dev/dsk/c0t67d0s0
> * /dev/dsk/c0t67d0s0 partition map
> *
> * Dimensions:
> * 512 bytes/sector
> * 133 sectors/track
> * 27 tracks/cylinder
> * 3591 sectors/cylinder
> * 4926 cylinders
> * 4924 accessible cylinders
> *
> * Flags:
> * 1: unmountable
> * 10: read-only
> *
> * First Sector Last
> * Partition Tag Flags Sector Count Sector Mount Directory
> 0 2 00 0 215460 215459 /
> 1 3 01 215460 373464 588923
> 2 5 00 0 17682084 17682083
> 3 4 00 588924 517104 1106027 /usr/openwin
> 4 7 00 1106028 100548 1206575 /var
> 5 0 00 1206576 1389717 2596292 /opt
> 6 4 00 2596293 714609 3310901 /usr
> 7 8 00 3310902 14371182 17682083 /export/home
>
> We have 5 * 9G disks - the root disk, u1, u2, u3 and u4. All Oracle
> products sit on the u1, u2,u3, u4.
>
> The root disk has /, /usr/openwin, /var, /opt, /usr and /export/home
> partitations.
>
> We think we could do 2 options. The 1st one is -
> 1). backup the all systems files on to tapes - (using tar) - Do twice to
> make sure in case the first set of copy has read problem.
> 2). do oracle exports backup for all instances on to tape.
> 3). deallocates the sectors given to /export/home (where not essentail
> files are stored).
> 4). move the /var from the current allocated sectors to new sector by
> using the steps mentioned in MOVING /var summary email.
>
> The 2nd one is -
> 1). Do all the same backup procedures mentioned in the 1st option.
> 2). Unmount the u1, u2, u3, u4 disks.
> 3). Reconfigure/repartition the root disk.
> 4). Restore the files from the tapes for root disk
> 5). Remount the u1,u2, u3, u4
>
> I just want to have some idea before doing anything. Any idea would be
> highly appreciated.
>
> Thanks
> Maw Maw
>

Thanks to Art Freeman, Ganeshan, Ray Delaney, David Harrington, Wolf Schaefer and Arthur Byrnes for their responses.

Art Freeman's (afreeman@lehman.com) advice -

Or, you could set a concatenated filesystem using Solstice Disk Suite or
Veritas Volume Manager.

Ganeshan (ganeshan@gcs.com.au) advice -

1. Stop all the process relating to oracle ,unmount u1, u2, ... comment out
the filesystems that get mounted during bootup in the /etc/vfstab
file ( relating to u1 u2 u3)
2. Also rename the startup files that fireup oracle in the /etc/rc2.d and
/etc/rc3.d directory.
3.rather than tar I would use ufsdump of the entire partition ie / /usr /var
/opt/ .
4. increasing your /var partition can be done by
a. reducing the /opt partition or changing /opt and subsequent partitions ie
/usr and /export/home.
5. format/select appropriate disk and partition , print command would tell
you the option you need to take.

6. boot cdrom -sw run format partition and change appropriate values
create newfs and ufsrestore appropriate partition that have been newfs'd
7 boot the system back in single user mode then multi use

Ray Delaney's (rdelaney@bbt.com) advice -

Do you have a spare disk on your system? If you do you could just set
that up to be the dummy root drive by sizing it and dumping the data to
it, shut down the system and then reboot on the backup disk. Once back
up you could resize your real root disk without ever having to go to
tape. If you are able to do something like this I would recommend it.
That is how I would do it here. I have attached the script in case you
were interested

David Harrington's (dharringt@deq.state.va.us) advice -

Add/use a large slice on another drive (not the root drive). Mount this
drive/slice as /tempvar.

cp -r /var /tempvar
umount /empvar

mount the drive/slice as /var.

Wolf Schaefer's (schaefer@wolfe.llnl.gov) advice

I've done it several time where I had to move /var and repartition
the old var. Make sure you are in single user mode before you
do anything with /var. Also when repartitioning, make sure that
you don't overlap any other used partitions.

Aurther Byrnes's (abyrnes@stetson.edu) advice -

It is hard to tell how much space is being used by each partition without a
"df -lk" listing, but from you sectors listing, you have no space
available, so you need to remove space from other file systems.

>4). move the /var from the current allocated sectors to new sector by
using the steps mentioned in MOVING /var summary email.

I didn't see that summary, but remember, you won't be Moving anything, you
will be destroying and recreating file systems.

Because you have all partitions in use, you will not be able to just expand
the /var, you will have to "move" /opt and /usr and reduce the size of
/export/home.

If I was doing this, I would prefer to have another disk to use, to make
moving the files systems easier. Putting them on tape will take a lot of
time, and a lot more risk than just copying to another disk. (It doesn't
even have to be the same controller.)

One of the things I did on a system that was running out of /var space was
to break out some of the larger /var sub directories and put them on
separate mount points.

Here is what the df -lk output looks like from that machine;
/dev/md/dsk/d8 38111 24290 10011 71% /
/dev/md/dsk/d13 625703 495098 68035 88% /usr
/proc 0 0 0 0% /proc
fd 0 0 0 0% /dev/fd
/dev/md/dsk/d20 456503 252479 158374 62% /var
/dev/md/dsk/d17 192807 156089 17438 90% /opt
/dev/md/dsk/d23 144799 109698 20631 85% /usr/openwin
/dev/md/dsk/d52 4814835 3520065 1054030 77% /var/mail

/dev/vx/dsk/rootdg/vol02
                     7854544 3552737 4066172 47% /var/news
/dev/md/dsk/d29 962983 3940 910898 1% /var/bb
/dev/md/dsk/d34 308695 83068 194767 30% /var/log
/dev/md/dsk/d42 1320014 533304 654710 45% /export/space1
/dev/md/dsk/d38 308695 172 277663 1% /var/spool/mqueue
/dev/md/dsk/d54 1071965 146171 818604 16% /var/log/OLD

(I have removed some lines for clarity.)

Notice the number of /var/* entries each one is a separate mount point.
This buy us two things;
One, it is easier to expand a small area than to recreate the entire /var
partition.
Two, it isolates the processes.
A lot of stuff uses /var , logs, nis+, mail, spools and such. We have had
our server crash, because some fine user decided to send a mail message
that exceeded the /var space this crash corrupted the nis+ stuff that was
in /var/tmp because both processes were trying to write at the same time to
a full partition. Now, if /var/spool/mqueue fills up, the only process
that gets clobbered is mail. Same with logs, if some error or condition
gives you large log files, the entire system doesn't crash.
The /var/log/OLD was just added as a place to hold the logs for a while
until we can get them moved to tape.

I guess that one of the points I am trying to make is that disks are cheap,
and it is better to add a disk and rearrange parts of file systems, them to
rebuild and reload the OS..

Also, when you are moving the /opt and /usr you will have to boot from cd
since the system won't be very useable, during the time that the disk
partitions have been changed in size and need to be newfs .

Sorry to ramble, but so that we are on the same page, here is what I see as
the steps to increase your /var in the way you were suggesting;

move /export/home;
Copy /export/home to tape
umount /export/home
run format and reduce size of /export/home partition
newfs new /export/home partition
mount new /export/home
copy tape to new /export/home

all of the above steps can be done without rebooting, (unless you have
strange stuff in /export/home.)

move /usr;

copy /usr to tape
reboot from cd (Some system process use /usr, so you will not be able to
umount it in most cases)
run format and change sector start/stop of /usr partition
(sure hope that tape is good!)
newfs new /usr partition
copy tape to new /usr
reboot

move /opt
some system stuff, especially Sun add on packages like to use /opt, so if
you can umount it, then you can do it just like /export/home otherwise it
is done like /usr

move /var
almost every program uses /var so you will have to boot off of cd and the
process is similar to moving /usr

What we did -

Perform 2 sets of backups for the whole system based on individual disks. (using tar)
Perform one set of UFSDUMP backup for each partition under the root directory. (should have two sets - Thanks Ganeshan for recommending to use UFSDUMP )
Commented out the scripts from rc2.d (Thanks Ganeshan)
Repartition the /export/home and restored.
Test on mounting/unmounting/ufsrestoring file systems by booting from CDROM. (This was done before reconfiguring the /usr partition - Thanks Arthur for pointing this out.)
Repartition the /usr
Repartition the /opt
Repartition the /var
Ufsrestore the /var
Ufsrestore the /opt
Ufsrestore the /usr

The problem encountered -

Couldn't succeed restoring /usr first (May be - because of some symbolic link or other files look for some information from /opt )- so we tried restoring /var , /opt and then /usr in sequence. And it worked.

Thanks again SUN Managers.
Maw Maw





This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:19 CDT