in order to free space from root filesystem....

[Livia]

Hi all,

My HP-UX 11.11 has a 200M / filesystem.
Now it is 89%.......including 100M /etc directory in it.

Since root filesystem cannot be extend, I plan to:
1) create a new filesystem /etcs on a new volumn
2) copy all files from /etc to /etcs(cp -rp /etc/* /etcs)
3) remove /etc(rm -Rf /etc)
4) make a soft link /etc link to /etcs instead(ln -s /etc /etcs)

So that I can reduce the using space of / filesystem......in theory.


But this server is an important production server, I am afraid what I do will cause some critical problem.

Is there anybody has suggestions?
Can I do what I plan to do as I describe above?

Thanks for any help/suggestion.

[Steve Steel]

Hi


You need /etc on the root system to reboot.

Stuff like mnttab and fstab.

Moving it is a bad idea

Look at sam
routine tasks
system log files

or selective file removal to make space


Steve Steel

[Sandy Chen]

Hi Livia,

Sounds good for me, to extend / filesystem, I would prefer ignite, backup/restore. If that not possible then, doing what you planned sounds good. Just make sure you have a proper backup before you do all that.

Regards,
Sandy

[MarkSyder]

As Steve says, /etc cannot be a separate filesystem, so do not do what you planned.

First question: how long has / been 89% full? If it is not growing, there is no problem.

Second question: assuming / has recently grown, do you have any ordinary files in /dev? The most common cause of / suddenly growing is someone mistyping a tape device name and creating a large text file in /dev.

If / is growing and there isn't a large ordinary file in /dev, check to see if any applications are writing to / that would be better writing to a dedicated lvol/filesystem.

Mark Syder (like the drink but spelt different)

[Robert-Jan Goossens_1]

I agree with Mark and Steve, not a good idear to move /etc to a seperate filesystem.

Could you post the output of

# du -kx / | sort -rn | head -20

Regards,
Robert-Jan

[john korterman]

Hi Livia,

first, find out what comsumes the space, e.g.:

# cd /etc
# du -sk *

or
# find / -type f -xdev -size +3000000c


regards,
John K.

[Matti_Kurkela]

Your planned action will definitely cause a critical problem.

When HP-UX 11.11 boots, the kernel will find the root filesystem using the information stored by the lvlnboot command. After that, all other filesystems are mounted by the startup scripts, using the mount command and the /etc/fstab file.

If /etc is a soft link to another filesystem, there is no way to find /etc/fstab if /etcs is not mounted... and at boot-time, there is no way for the mount command to find out that it's supposed to mount some LV to /etcs.

You won't even get as far as the single-user mode, as the init process will need to read /etc/inittab immediately after it starts. The location of /etc/inittab is hardcoded: you cannot tell init to find it anywhere else.

In short: Don't do it. There are several very good reasons why /etc must be located on the root filesystem. Moving it will make your system unbootable.

As an alternative, use "du -kx / | sort -rn" to find the biggest consumers of the root filesystem.
My guesses:
- maybe a big core file somewhere?
- a typo may have caused a file to be created in /dev.
- if you have large volume groups (SAN environment maybe?), /etc/lvmconf may have large vg*.conf and vg*.conf.old files.

MK

[Steve Steel]

Hi


Also

du -s /var/adm/crash/*


Look for core files

Large syslog files to prune with sam


du -s /var/adm/*|sort -n


Steve Steel

[Geoff Wild · Accepted solution]

Do you have online jfs?

If so - you may be able to extend root - live!

Yes - all you need is a spare disk (or break your mirror and use it).

See my "not for the faint of heart" instructions here:

http://www.met.ca/itrc/index.php?option=com_content&task=view&id=89&Itemid=2

Always have a good backup!

And yes - ignite is the preferred way to do this - but I just can't stand taking a system down (after all - HP-UX isn't Windoze).


Rgds...Geoff

[TwoProc]

Livia,

You can move *some* of /etc, those being /etc/opt and /etc/lp.

And you'll more than likely fix your problem. It fixed ours.

Go through your same steps, using them for making mount points and moving both /etc/opt and /etc/lp.

This will take care of a lot of your space issues, and will still allow a clean boot up, because none of the items in /etc/opt and /etc/lp are required for booting (at least for us). Make sure and TEST THIS on at test server first, because it is possible that you're using something in here that is needed in early in the boot, though I doubt it. All I have in there is stuff that is started later during the boot (at init level 3), well after /etc/opt and /etc/lp have already been mounted.

On my system, /etc/opt is 34M and /etc/lp is 22M. Your mileage may vary, but this saved me 56M of my 200 Meg root file system - which was plenty enough to save me from having to reload the OS from ignite.

[Livia]

Thanks for all suggestions! (Now I am so glad that I ask before doing so.....)

The / filesystem has been about 85% for at least a year. It has increased resently since lots of patches installed on it.
> bdf
Filesystem kbytes used avail %used Mounted on
/dev/vx/dsk/rootdg/rootvol 204800 182168 22632 89% /
/dev/vx/dsk/rootdg/standvol 295024 78432 187088 30% /stand
/dev/vx/dsk/rootdg/varvol 12288000 4045960 8178280 33% /var
/dev/vx/dsk/rootdg/usrvol 3268608 1195992 2056488 37% /usr
/dev/vx/dsk/rootdg/tmpvol 3268608 2451752 810608 75% /tmp
/dev/vx/dsk/rootdg/optvol 3268608 1338256 1915288 41% /opt
/dev/vx/dsk/rootdg/homevol 4317184 2621456 1683184 61% /home
/dev/vx/dsk/rootdg/data 36700160 29834588 6651060 82% /data
/dev/vx/dsk/DEVDG/oracle 133693440 81058504 52223760 61% /DEVDB/oracle
/dev/vx/dsk/DEVDG/oracle1 89313504 42312496 46633856 48% /DEVDB/oracle/oradata/INSTANCE2


> du -kx / | sort -rn | head -20
174840 /
94960 /etc
64032 /etc/vx
48480 /sbin
32992 /etc/vx/type
29480 /etc/vx/static.d
28768 /etc/vx/static.d/build
18456 /etc/opt
16328 /nsr
16176 /nsr/applogs
15632 /nsr/applogs/msglog
14936 /etc/vx/type/static
13912 /.VRTSob
13856 /.VRTSob/extensions
13032 /etc/opt/resmon
8960 /etc/vx/type/gen
7800 /etc/opt/resmon/lbin
6784 /etc/vx/type/raid5
5912 /sbin/fs
4448 /etc/emc

It seems /sbin should keep on root filesystem.
I use vxvm on this server, so /etc/vx should not be moved(?)
I think /nsr is safe to be moved to another filesystem, but it only take 8% space of the whole / filessystem.
/etc/lp is very small, /etc/opt is safe to be moved to another filesystem (according to TwoProc's experience), but it takes only 9% of the whole / filesystem......

So, maybe I could try Geoff Wild's resolution first to see if it works on vxvm first....?

[Bill Hassell]

174840 /
94960 /etc
64032 /etc/vx
48480 /sbin
32992 /etc/vx/type
...

Yes, /sbin must remain on the root filesystem. Note that a small to mid-sized server will use about 30-40 megs for both /etc and /sbin, so /sbin is fine. /etc is about 3x the usual size but because most of the space is in the /etc/vx tree, it would seem that you have an enormous disk farm. However, I don't see dozens of mountpoints or multi-terabyte volumes, so it would seem there might be a lot of small LUNs. If this system will continue to grow with more disk LUNs, you'll have to re-ignite the system with a much bigger /, at least 500 megs.

[omar abdullah]

HI
i hane HP 9000 K450
ROOT FILE SYSTEM IS FULL
CORE FILE ALWAYS BIG
I REMOVE CORE FILE DAILY
AFTER CORE FILE REMOVE ROOT FILE SYSTEM CAME 22%
root file system is 92 M

WHY CORE FILE DAILY INCREASE


Regards
Abdullah Omar

[Dennis Handly]

>Abdullah Omar: WHY CORE FILE DAILY INCREASE

You need to ask your questions in your own thread so you can give proper credit for the answers. You can point to this thread if there is any background that is useful for your question.

[Livia]

Because most of thefilesystem cannot be moved from root filesystem, I think maybe the best way to make enough space in root filesystem is expand filesystem space be using Ignite.