storage in root is 100% usage, what to remove to free it

[ArAgOnHaMz]

Hi,

You can see below my  space at '/' is 100% use. 

 Filesystem            Size  Used Avail Use% Mounted on

 /dev/cciss/c0d0p6      20G   19G     0     100%    /

 /dev/cciss/c0d0p7     9.7G  151M  9.1G   2% /tmp

 /dev/cciss/c0d0p5      20G  2.0G   17G  11% /usr

 /dev/cciss/c0d0p3      20G  6.5G   12G  36% /var

 /dev/cciss/c0d0p2      20G  3.5G   15G  19% /opt

 /dev/cciss/c0d0p1     2.0G   41M  1.8G   3% /boot

 /dev/mapper/vg0-lv0   8.8T  7.0G  8.3T   1% /global/home

 /dev/mapper/vg1-lv1   7.6T   22G  7.2T   1% /global/apps

Im new to these things, please help me how to find out what is exactly causing this issue. I wanted to know maybe is there any hidden files or something that cause this problem. Or maybe is it a harddrive failure.?

Thanks in advance

Hamar

P.S. This thread has been moved from storage>General to Linux > sysadmin. -HP Forum Moderator

[Johan Guldmyr]

Hi, 

you can use 'du' to find out what is using the most. For example this:

cd /

du -ch --max-depth=3 >> /tmp/listall 

would give you a list in /tmp/listall that has all the directories within 3 levels and how large each is.

20G for /opt and /usr was perhaps a bit too much?

[ArAgOnHaMz]

I can do that and infact i have tried listed themout, but the problem is that whenever i use the command du, it just stops there on the screen and hang. Any other ways to see them.

[Johan Guldmyr]

If you run the command I showed then all the files should be listed in /tmp/listall, not on the screen.

If there's nothing in there either, check /var/log/messages (might vary, what OS are you running) for errors.

There are other tools than du to list files (find for example).

[Matti_Kurkela]

The "du" command will search through all the directories (optionally up to the requested depth) to check the disk space occupied by each file and directory. This can take a while, especially if you have a huge number of tiny files somewhere.

But if the du command really hangs forever, then there might be filesystem corruption and/or hard drive failure. Use "dmesg | less" to see a buffer of latest kernel messages: does the dmesg output contain anything that looks like a disk error?

The problem with the "dmesg" output is that it usually does not include timestamps for the messages. Usually, the important messages from dmesg are also stored to the syslog files in /var/log, which include a timestamp for each message. If you have a filesystem/disk problem, looking at the logs might allow you to determine when the problem started.

Note that if you have a filesystem/disk problem that causes processes to hang, any backups taken after the problem started might well be incomplete.

[ymahesh81]

Hamar,

Compare the o/p of du -sh / & df -h / ; if there is any deleted files are still open which you can find by the command lsof | grep -i deleted and find top usage directories with command ; du -sh / | sort -n -r | head -n 10