/dev/root file system full

[Andre Lemon]

Does anyone know the directories which should contain file that can be deleted to free up space?


Thank you.

Andre'

[Bill McNAMARA_1]

look in /dev for really large files.

btw /dev/root should really be /dev/vg00/lvol3. Check your /etc/fstab

Later,
Bill

[Bill McNAMARA_1]

look in /dev for really large files.
also in /etc/

btw /dev/root should really be /dev/vg00/lvol3. Check your /etc/fstab

however, issue a bdf so we can see your filesystem mountpoints!

Later,
Bill

[John Poff]

Hi,

First thing I would look for is core files. Next, go to /dev and look for bad device file names. Maybe something thinks it is writing to a device file and it is writing to a real file instead.

JP

[V. Nyga]

Hi,

all in /var/adm/crash.
Older files in /tmp, /var/tmp, /usr/tmp (maybe ask here before).
Check if there are big files in /dev.

Volkmar

[john korterman]

Hi,
check that all your disks are available. If a disk drops off a mount point, the data supposed to go there will be written in the root dir instead.

regards,
John K.

[Pete Randall · Accepted solution]

Andre'

Since this is your root file system, you need to look at everything that is not a mount point. One of the prime suspects is under /dev - look for non-existent device file like /dev/rmt/om (the letter o, rather than 0). Look underneath mount points - if /var was unmounted at some point and a huge file was written to it, the file ends up occupying space under the root file system rather than under the mount point.

Use du -sk /* |sort -n to find the biggest directories under / that are not mount points and then drill down into those to find out what's using the space.

Is root's home directory under /? If so, look for large files there.

Look for core files - "find / -name core"


Pete

[Michael Steele_2]

Appears to be two problems here. (?)

As indicated above /dev/root is /dev/vg00/lvol3 and mounts to /.

'/dev/root' is a indication of a corrupted /etc/mnttab file.

rm /etc/mnttab
bdf
-or-
mount -a

...to rebuild.

But, if its 100%, this is a big problem. Try these:

find /dev -type f (* delete any files reported, like /devrmt *)

find / -xdev -ctime 0 (* If you just made a mistake then this will find files accessed today. *)

du -x / | sort -rn | more (* list out / biggest files in reverse sorted order *)

[Uday_S_Ankolekar]

Look for any /dev/rmt/om in the /dev or any root directory.

Most of the time it's users mistake while running some backup or tar command assigned to tape or any device instead of 0mn by mistake typed omn (letter o)

-USA..

[Andre Lemon]

Here is the bdf listing:

Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 143360 142439 921 99% /
/dev/vg00/lvol1 83733 41928 33431 56% /stand
/dev/vg00/lvol8 1228800 731461 466564 61% /var
/dev/vg00/lvol7 770048 460481 290264 61% /usr
/dev/vg01/lvol18 4096000 2104 83803
50% /twpspare
/dev/vg00/lvol4 65536 17268 45309 28% /tmp
/dev/vg00/lvol9 8192000 6438260 1645121 80% /production
/dev/vg00/lvol6 770048 459551 291131 61% /opt
/dev/vg00/lvol5 102400 49440 49681 50% /home
/dev/vg01/lvol19 10035200 9237769 748224 93% /develop
/dev/backup/backup 54272000 44608992 9587576 82% /backup

those tmp dir's and core are 0

[Dario_1]

Andre

Look for any core file within the root directory.

find / -name core

also

cd /dev and execute the following find /dev -type f this command will show all the regular files within that directory which are not supposed to be there.

A bad tape device name when swapping tapes will create a big file there that does not belong to it.

EX.

/dev/rmt/om or /dev/rmt/Om

Regards,

DR

[Andre Lemon]

how do you remove a file using its inode number?

total 196452
-rw------- 1 root root 100575232 Apr 28 04:54 1m
crw-rw-rw- 2 bin bin 205 0x003080 Mar 30 2000 1mb crw-rw-rw- 2 bin bin 05 0x003040 Mar 30 2000 1mn
crw-rw-rw- 2 bin bin 205 0x0030c0 Mar 30 2000 1mnb
crw-rw-rw- 1 bin bin 205 0x003000 Apr 28 08:39 c0t3d0BEST
crw-rw-rw- 2 bin bin 205 0x003080 Mar 30 2000 c0t3d0BESTb
crw-rw-rw- 2 bin bin 205 0x003040 Mar 30 2000 c0t3d0BESTn
crw-rw-rw- 2 bin bin 205 0x0030c0 Mar 30 2000 c0t3d0BESTnb
crw-rw-rw- 1 bin bin 205 0x003001 Mar 30 2000 c0t3d0DDS
crw-rw-rw- 1 bin bin 205 0x003081 Mar 30 2000 c0t3d0DDSb
crw-rw-rw- 1 bin bin 205 0x003041 Mar 30 2000 c0t3d0DDSn
crw-rw-rw- 1 bin bin 205 0x0030c1 Mar 30 2000 c0t3d0DDSnb
crw-r--r-- 1 bin bin 205 0xfffffe Mar 30 2000 stape_config

[ssudhir]

hi

pls check for the following
1) /tmp directory
2) /var/adm/crash directory
3) check for core files and delete them if not required
4) /dev/ directory... check for any large file created
5)/etc/wtmp and /etc/btmp file... u can just touch those file...


ssudhir

[Marco Santerre]

Also check in /etc for any files that might be a backup of the real file.. eg.. /etc/lvmtab.old or /etc/lvmconf.old or things like that..

You may wanna check also if you have directory called /root and if someone decided to store things in it.

[ssudhir]

hey
please do not try to remove any file with crw and brw...

ssudhir

[john korterman]

Hi again,
keep in mind that the disk consumption could also be caused by many smaller files; therefore look for big directories in the root directory, e.g.:
# du -kx / | sort -rn
in order to look for something suspicious.

regards,
John K.

[Pete Randall]

Andre'

It looks you found the culprit in the /dev directory:

total 196452
-rw------- 1 root root 100575232 Apr 28 04:54 1m


You can just do "rm 1m" (assuming you've cd'd to the directory first or "rm /dev/rmt/1m" if not).


Pete

[Andre Lemon]

Thanks pete, i had to remove the file using the
inode method. I am all set now.

Andre'


This question is closed, no more help it needed
with it nor will any more points be assiged, that to you all for your help.