Extent root file system

[JJ_21]

I ran the following command to extent root file system.
Fsadm â F vxfs â b 144384 /

I got following errors:
Fsadm: /dev/vg00/rlv0l3 is currently 143360 sectors â size will be increased write failure at block 4338686 : No such device or address.

Does anyone know how to fix this problem?

Thanks in adva

[Pete Randall]

The root file system (/) needs to be contiguous. You're probably running into the swap area. The best way to accomplish this it to download and install Ignite
http://www.software.hp.com/products/IUX/index.html.
Then run make_tape_recovery -a /dev/rmt/_mn -I -v -x inc_entire=vg00 to back up your root volume group. Boot off the Ignite tape and interact with the recovery to resize your logical volumes.

A more important question might be: why do you need to enlarge /?


Pete

[RAC_1]

First of all /stand, swap space and / need to contigeous.

In order to increase any of them, you will have to use ignite and resize the partitions.

First check why you need to extend /. / is static file system and should not grow if you /var etc on different file systems. The good practise is to have /var on different filesystem.

[Pete Randall]

I confused myself with that one:

You're probably not running into the swap area but another logical volume. In any case, it's the fact that it has to be contiguous that's causing difficulties.


Pete

[Geoff Wild]

On top of ignite, you could also do this manually from LVM Maintenance mode.

As an example, I had to increase the size of /stand for a recent 11i upgrade.
Below, my lvol1 is stand and lvol2 is primary swap (used to have swap on lvol3 as well) and root is lvol4.


boot into LVM maintenance mode:

hpux -lm

vgchange -a y /dev/vg00
lvrmboot -r /dev/vg00
lvremove /dev/vg00/lvol2
lvextend -L 256 /dev/vg00/lvol1
extendfs /dev/vg00/rlvol1
lvcreate -L 1024 -C y -r n -n lvol2 /dev/vg00
lvlnboot -b /dev/vg00/lvol1
lvlnboot -r /dev/vg00/lvol4
lvlnboot -s /dev/vg00/lvol2
lvlnboot -d /dev/vg00/lvol2
lvlnboot -R
reboot -r

What you could do is remove your primary swap - extend root - then add swap back with what is left.

Of course this is not for the meek of heart :)

The ignite way is probably easier...

The real question is, why do you want to increase your root filesystem?

Better to move that which does not belong into a new lvol...

Rgds...Geoff

[Helen French]

Before doing this, you need to make sure that you have all latest patches installed on the system, especially PHKL_19202 (for 11.0).

Check the LV which comes after root (/) volume:

# pvdisplay -v /dev/dsk/cxtydz (specify the root disk there).

Since the root should be contiguous, you need to move the next LV which comes after lvol3 to another disk through 'pvmove' command. Once you free that space, you can extend the LV (lvextend) and then the FS with fsadm command. Remember to create a Ignite recovery tape for safe sid and boot system in LVM maintenance mode.

Note: If your applications and data are on different LVs, you really don't need to extend the root after OS installation. Check and see if you have any unwanted data residing on root. Also, see if you can use symbolic links for your "must-be -in-root" applications.

[JJ_21]

The reason I need to extent root file system is because the root file system is full. Does anyone know how to check all of files inside of root file system.

Thanks again.

[Pete Randall]

JJ,

First, do a "vgdisplay -v vg00" and a "bdf" to determine what file systems you have that are not part of the / file system. Then do a "du -sk /* |sort -n" to see the size of what exists under /, ignoring the other mounted file systems. This will tell you where most of the space is being consumed.


Pete

[Helen French · Accepted solution]

One easiest way would be:

1) Check the biggest directory in root (/):

# du -k -x | sort -rn | pg

2) Go to each big subdirectories (which will be listed on top, running the above command) and check for bigger files there:

# find . -depth -xdev -size +1000 -print

3) Check and if you think the directories/files are not needed, move or delete it.

Note: One common reason for root file system full is a big file in /dev. If by mistake, somebdy gave /dev/rmt/Om instead of /dev/rmt/0m during a backup, that might make the root file system full!

[Geoff Wild]

Do what Pete says...

Then...

Check for core files:

#!/bin/sh
HOST=`uname -n`
cat /dev/null >/tmp/core.find.txt
for i in `find / -name core -type f`
do
file ${i} >>/tmp/core.find.txt
done
if [ `ls -s /tmp/core.find.txt |awk '{print $1}'` -ne 0 ]; then
mailx -s "core files on $HOST" you@yourdomain.com fi


Rgds...Geoff

[Pete Randall]

JJ,

One other potential problem is files lurking underneath mount points. If a file system was unmounted and a large file got written to it while it was unmounted, the file actually consumes root space. This one got me back in my early days with HP-UX.


Pete

[Elmar P. Kolkman]

As for Petes suggestion, that is quite easy, though possibly time consuming, to test: do an 'du -skx /' and compare the result value to the used column from bdf. If they differ much, there are 2 possibilities: Pete's suggestion with files under mountpoints, probably even in use (daemons that start before the filesystem is mounted, for instance) or there are files removed while they are still in use. A reboot, probably to single user mode, can help you solve this. Check out all mountpoints while in single user mode and these two issues are resolvable.

As for the rest: check out which directories contain most data in /. Do an 'du -skx /* | sort -n' and filter out all directories that are mount points.

du -skx /* | sort -n | while read size dir
do
if bdf | grep -v -q "$dir$"
then
echo "$size $dir"
fi
done

Remember the trailing '$' in the grep, because you want parents of mountpoints in your list! (/oracle should in your list, even though /oracle/P01 shouldn't, for instance)
I had a situation at my site where I had dropped a depot file in a directory that is on 99.9% of the systems on a seperate filesystem, but 1 server had it on / instead, resulting in a message from the monitoring system. Perhaps someone at your site made the same mistake. It should show up in the du list.

[JJ_21]

Hi everyone,

I used # du -k -x | sort -rn | pg command and found the answers. I get rid off the unused big file. Now, I have 59% available space now. It is great!

Thanks again for help.

JJ