/ is full

[hemant dubey_1]

Hi

/ is 90% in my hp server and i am not able to find any logfiles in / which can reduce it here is the output of 20 big files and directories wich are occuping the space please suggest which file i can delete or compress..

fsc004:[/etc] # du -x / | sort -rn | head -30
253474 /
158584 /etc
118012 /etc/vx
81496 /sbin
58746 /etc/vx/type
58720 /etc/vx/static.d
57350 /etc/vx/static.d/build
23922 /etc/vx/type/static
23654 /etc/opt
17604 /etc/vx/type/gen
13000 /etc/vx/type/raid5
11676 /sbin/fs
10606 /oracle
10116 /etc/opt/resmon
7924 /etc/opt/resmon/lbin
7700 /etc/lp
7038 /etc/opt/samba
6990 /etc/opt/samba/codepages
6940 /sbin/fs/vxfs
5988 /etc/lp/interface
4974 /etc/lp/interface/model.orig
4818 /etc/lvmconf
4514 /oracle/send
4218 /etc/vx/type/fsgen
3502 /sbin/fs/hfs
3232 /etc/opt/wbem
3228 /etc/opt/wbem/mof
2920 /etc/opt/cifsclient
2852 /etc/opt/cifsclient/unitables
1974 /etc/opt/resmon/lib

[AwadheshPandey]

http://www.unix.com/hp-ux/26934-what-do-when-file-system-hp-ux-box-full.html
http://www.unix.com/linux/27716-root-filesystem-size-full.html

[MarkSyder · Accepted solution]

Is it growing? I have a system with / at 87%. It's been 87% for a long time, so it doesn't bother me.

If it is growing you probably have a process that's writing to / but would be better writing to a different lvol.

The usual suspect in a case like this is a mistyped tape device name creating a large file in /dev, but your output doesn't show /dev, so I don't think that's likely in your case.

Mark Syder (like the drink but spelt different)

[whiteknight]

Hi

your /oracle should not in /
your /oracle/send too


I suspected you restore to /

please move them

WK

[V. Nyga]

Hi,

can you show us 'bdf' of your system?

Volkmar

[hemant dubey_1]

thanks all for your inputs but issue is there
here is the output of bdf

$ bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 204800 184091 19440 90% /
/dev/vg00/lvol1 199381 57299 122143 32% /stand
/dev/vg01/lvol5 2097152 903834 1118748 45% /work
/dev/vg00/lvol8 4096000 3010029 1020099 75% /var
/dev/vg00/lvol7 2048000 1224379 772184 61% /usr
/dev/vg00/lvol10 204800 21114 172244 11% /usr/soe
/dev/vg01/lvol6 1048576 521152 494470 51% /usr/cachesys50
/dev/vg02/lvol1 1048576 298987 703051 30% /usr/cachesys41
/dev/vg01/lvol1 524288 72727 423372 15% /usr/cachesys
/dev/vg02/lvol5 10240000 3716962 6349984 37% /users
/dev/vg00/lvol6 204800 1246 190899 1% /tmp
/dev/vg00/lvol5 2048000 1350188 654208 67% /opt
/dev/vg00/lvol9 204800 55467 140046 28% /opt/tng
/dev/vg00/lvol4 102400 53586 45784 54% /home
/dev/vg02/lvol6 524288 6529 485406 1% /database50/wij
/dev/vg02/lvol7 131072 71151 56181 56% /database50/journal
/dev/vg02/lvol2 31621120 25658912 5869296 81% /database41
/dev/vg02/lvol4 524288 78732 417715 16% /database41/wij
/dev/vg02/lvol3 131072 3126 119953 3% /database41/journal
/dev/vg01/lvol2 12288000 8325650 3838530 68% /database
/dev/vg01/lvol4 524288 1229 490375 0% /database/wij
/dev/vg01/lvol3 1024000 88939 876682 9% /database/journal
/dev/vg03/lvol1 22974464 20071380 2863396 88% /backup

[John Waller]

Hi

What is in the /etc/vx directory as that is taking up nearly half of the total space. I don't have a directory called that so I'm guessing it's not part of the standard O/S install and is an additional product. If it is required and likely to grow, you may need to look at creating a link so the information is in a serarate file system.

[hemant dubey_1]

fsc004:[/] # ll /etc/vx/static.d/build
total 57350
-r-xr-xr-x 1 bin bin 29362205 Oct 6 2004 vold.o

this file is taking 29 MB space i dont know what is the use of this file.. Could someone suggest if i can make mv or make a link of this file
/etc/vx/static.d/build/vold.o

[V. Nyga]

Hi again,

first /etc/vx is ok - i've it too, and it's static (not growing).
Then - your
/dev/vg00/lvol3 204800 184091 19440 90% /
is very small, so not thought for additional software, so as said before you should move /oracle, then you should be ok.

Volkmar

[V. Nyga]

fyi - vx seems to be Veritas File System (Online JFS)

[Pete Randall]

The /etc/vx directory is, I believe, related to VxVM the Veritas Volume Manager, rather than Online JFS. If you're not using VxVM, you could try swremove'ing it.


Pete

[rmueller58]

Check for the existence of a large file in /dev/rmt where someone attempted to backup a file but mistyped the device name.

Check /var/adm/syslog/

Check your database logs (if this is a database server) zero them out

cd
echo > logname.log


We had both problems in the past.




Your standard size for 0m, 1m, etc, are small (see below on healthy system)

crw-rw-rw- 2 bin bin 205 0x000000 Aug 10 10:17 0m
crw-rw-rw- 2 bin bin 205 0x000080 Jun 18 15:18 0mb
crw-rw-rw- 2 bin bin 205 0x000040 Jun 20 13:18 0mn
crw-rw-rw- 2 bin bin 205 0x0000c0 Jun 18 15:18 0mnb
crw-rw-rw- 2 bin bin 205 0x033000 Oct 19 04:25 1m
crw-rw-rw- 2 bin bin 205 0x033080 Jun 18 15:18 1mb
crw-rw-rw- 2 bin bin 205 0x033040 Jun 18 15:18 1mn
crw-rw-rw- 2 bin bin 205 0x0330c0 Jun 18 15:18 1mnb
crw-rw-rw- 2 bin bin 205 0x000000 Aug 10 10:17 c0t0d0BEST
crw-rw-rw- 2 bin bin 205 0x000080 Jun 18 15:18 c0t0d0BESTb
crw-rw-rw- 2 bin bin 205 0x000040 Jun 20 13:18 c0t0d0BESTn
crw-rw-rw- 2 bin bin 205 0x0000c0 Jun 18 15:18 c0t0d0BESTnb
crw-rw-rw- 1 bin bin 205 0x000001 Jun 18 15:18 c0t0d0DDS
crw-rw-rw- 1 bin bin 205 0x000081 Jun 18 15:18 c0t0d0DDSb
crw-rw-rw- 1 bin bin 205 0x000041 Jun 18 15:18 c0t0d0DDSn
crw-rw-rw- 1 bin bin 205 0x0000c1 Jun 18 15:18 c0t0d0DDSnb
crw-rw-rw- 2 bin bin 205 0x033000 Oct 19 04:25 c3t3d0BEST
crw-rw-rw- 2 bin bin 205 0x033080 Jun 18 15:18 c3t3d0BESTb
crw-rw-rw- 2 bin bin 205 0x033040 Jun 18 15:18 c3t3d0BESTn
crw-rw-rw- 2 bin bin 205 0x0330c0 Jun 18 15:18 c3t3d0BESTnb
-rw------- 1 root sys 0 Jun 22 07:54 rStp0
crw-r--r-- 1 bin bin 205 0xfffffe Jun 18 15:18 stape_config

[Pete Randall]

Or simply check for the existence of a regular file in /dev:

find /dev -type f

There should be none.


Pete

[Geoff Wild]

Another option is to increase the size of /

Your / is only 200MB - you can either use ignite to resize your vg00 (requres downtime) or if you have a spare disk - or if / is mirrored, then you can use the following procedure - make sure you have a good backup - this can be done on line without an outage:

Not for the faint of heart.

No outage required , if you have online jfs.
If you do not have online jfs , do all the following in LVM maintenance mode.
Note: this will only work if SWAP is NOT the next lvol after /

a. Login as root.
b. Find out a free disk / un mirror the rootvg and make that disk free.
c. find out the next logical volume after lvol3(assumed lvol3 is root)
d. pvmove that logical volume onto the newly added disk
[ pvmove -n /dev/vg00/lvol4 /dev/dsk/CURRENT /dev/dsk/NEW]
e. now you should be able to increase root filesystem to an additional `size_of_the_lvol4`.
f. pvmove the lvol4 back to root vg ( vg00)

boot,swap and root are the only lvols that needs a contegeous policy. so , it does not matter where lvol4 is.

Example, move lvol4 away from lvol3 , thus creating a contegeous space right after lvol3. If you need more space on "/" you will be able to move lvol5 ...6 to the next disk and do the stuff. Do remember to migrate them back to the original disk.

Now, if you have mirrored root vg, then break the mirror before you do this.


Practical Example (actual test)

# bdf |grep vg00
/dev/vg00/lvol3 204800 151616 53184 74% /
/dev/vg00/lvol1 125808 49064 64160 43% /stand
/dev/vg00/lvol7 4194304 2501208 1680472 60% /var
/dev/vg00/lvol6 3145728 1856304 1279456 59% /usr
/dev/vg00/lvol5 524288 160992 361104 31% /tmp
/dev/vg00/lvol4 2097152 1833496 261656 88% /opt
/dev/vg00/lvol8 1048576 622656 422632 60% /home
/dev/vg00/lvol10 2097152 1270980 774595 62% /app


Find a spare disk (or break root's mirror and use that one):

strings /etc/lvmtab |grep c7t0d6
pvcreate -f /dev/rdsk/c7t0d6
vgextend /dev/vg00 /dev/dsk/c7t0d6
lvdisplay -v /dev/vg00/lvol4 |more
lvreduce -m 0 /dev/vg00/lvol4
lvdisplay -v /dev/vg00/lvol4 |more
pvmove -n /dev/vg00/lvol4 /dev/dsk/c0t6d0 /dev/dsk/c7t0d6


lvreduce -m 0 /dev/vg00/lvol3
lvextend -L 1024 /dev/vg00/lvol3
fsadm -b 1024M /

pvmove -n /dev/vg00/lvol4 /dev/dsk/c7t0d6 /dev/dsk/c0t6d0
vgreduce /dev/vg00 /dev/dsk/c7t0d6


lvextend -m 1 /dev/vg00/lvol3
lvextend -m 1 /dev/vg00/lvol4


# bdf |grep vg00
/dev/vg00/lvol3 1048576 151640 890456 15% /
/dev/vg00/lvol1 125808 49064 64160 43% /stand
/dev/vg00/lvol7 4194304 2506048 1675672 60% /var
/dev/vg00/lvol6 3145728 1856304 1279456 59% /usr
/dev/vg00/lvol5 524288 160992 361104 31% /tmp
/dev/vg00/lvol4 2097152 1833552 261600 88% /opt
/dev/vg00/lvol8 1048576 622656 422632 60% /home
/dev/vg00/lvol10 2097152 1270980 774595 62% /app



Rgds...Geoff

[Stan Sieler]

BTW, that initial list you posted was a list of
large directories, not large files.

To find large files...

The following command (run as root) will
list files larger than about 10 MB...

find / -type f -size +10000000c -exec ls -l {} \;