what is taking up space on / partition

CHIadam · 06-06-2012, 02:44 PM

Hello all,

I am trying to figure out what is taking up so much space on my / partition. when I run

#df -h

I get

/dev/sda3 15G 11G 3.5G 76% /

However when I run
#find / -type f -size +250M -exec ls -lh {} \; | awk '{print $5 ": " $NF}'

I get (I have to xxx out all the file names):

351M: /xxx
429M: /xxx.tar
66G: /proc/kcore
1.1G: /xxx.gz
251M: /xxx
528M: xxx.unl
395M: /xxx.txt
2.0G: /xxx.txt
472M: /xxx.log
1.4G: /xxx.audit.log
934M: /xxx.log
770M: /xxx.audit.log_bak
583M: /xxx.debug
1.9G: /xxx

Question 1) So my question is, how is there a 66G directory in my / partition that is only 15G large?

Question 2) Anyone have any input on a better approach for this noob?

Thanks!

Doc CPU · 06-06-2012, 03:11 PM

Hi there,

Quote:

Originally Posted by CHIadam

I am trying to figure out what is taking up so much space on my / partition. when I run

#df -h

I get

/dev/sda3 15G 11G 3.5G 76% /

looks fairly reasonable. You're probably using a journaling file system (like ext3, for example). There is a certain percentage of the capacity reserved for the journal, and that space is reported as neither "Used" nor "Available". That accounts for the missing half gigabyte, I think.

Quote:

Originally Posted by CHIadam

#find / -type f -size +250M -exec ls -lh {} \; | awk '{print $5 ": " $NF}'

I get (I have to xxx out all the file names):

351M: /xxx
429M: /xxx.tar
66G: /proc/kcore
1.1G: /xxx.gz
251M: /xxx
528M: xxx.unl
395M: /xxx.txt
2.0G: /xxx.txt
472M: /xxx.log
1.4G: /xxx.audit.log
934M: /xxx.log
770M: /xxx.audit.log_bak
583M: /xxx.debug
1.9G: /xxx

Question 1) So my question is, how is there a 66G directory in my / partition that is only 15G large?

There isn't. The /proc directory is a virtual file system - that is, it doesn't exist as a physical directory on your HDD, and it doesn't take up any space. Its contents is generated on-the-fly by the kernel when it's being requested, and it's duplicated many times under different paths. Browsing the directory tree, as find does, you request every possible representation of the data, and obviously, that's an awful lot.

By the way, you seem to have a lot of strange files in your root directory. Usually, this directory should remain almost clean. There may be symlinks to the current kernel and initrd, but otherwise there should only be the standard Unix/Linux directories, no files.

Quote:

Originally Posted by CHIadam

Question 2) Anyone have any input on a better approach for this noob?

To achieve what exactly?

[X] Doc CPU

snowday · 06-06-2012, 03:12 PM

Welcome to the forums!

1) /proc is not a "real" folder that uses space on your hard drive. http://en.wikipedia.org/wiki/Procfs

2) 11gb used seems reasonable to me; I'm not sure what the problem is exactly. Which distribution are you using? I may be able to recommend some distro-specific housekeeping you can do to keep the size down.

Generally speaking you should not go around deleting/editing/moving files outside your /home folder. These are important system files and deleting them without understanding the consequences can break your system.

chrism01 · 06-06-2012, 05:55 PM

An alternate approach is to use the du cmd http://linux.die.net/man/1/du which has various options to analyse disk usage. One example would be

Code:

cd /

du -sh *

#OR to skip warnings about proc dir
du -sh * 2>/dev/null

sycamorex · 06-06-2012, 06:11 PM

ncdu might also come in handy.

CHIadam · 06-07-2012, 11:34 AM

noob double post

CHIadam · 06-07-2012, 11:35 AM

Quote:

Originally Posted by Doc CPU

Hi there,

looks fairly reasonable. You're probably using a journaling file system (like ext3, for example). There is a certain percentage of the capacity reserved for the journal, and that space is reported as neither "Used" nor "Available". That accounts for the missing half gigabyte, I think.

There isn't. The /proc directory is a virtual file system - that is, it doesn't exist as a physical directory on your HDD, and it doesn't take up any space. Its contents is generated on-the-fly by the kernel when it's being requested, and it's duplicated many times under different paths. Browsing the directory tree, as find does, you request every possible representation of the data, and obviously, that's an awful lot.

By the way, you seem to have a lot of strange files in your root directory. Usually, this directory should remain almost clean. There may be symlinks to the current kernel and initrd, but otherwise there should only be the standard Unix/Linux directories, no files.

To achieve what exactly?

[X] Doc CPU

Thanks Doc.

"To achieve what exactly?" I am trying to clean up the contents of this partition as it is hitting our disk usage alert monitor. I was wondering if there was a better way to find out what is taking up space, but I think my find | awk one liner did a great job.

I know there are a lot of strange files, I "xxx" them out because there is information regarding a trading application that I didnt want the world to see (or competitors).

Looks like I can clean up some logs and the get the %disk usage alert to go away.

Everyone else, thank you very much for your input. Greatly appreciated!

Doc CPU · 06-07-2012, 03:25 PM

Hi there,

Quote:

Originally Posted by CHIadam

I know there are a lot of strange files, I "xxx" them out because there is information regarding a trading application that I didnt want the world to see (or competitors).

I wasn't referring to the file names - I understood that you camouflaged them.
I was rather referring to the location: They shouldn't be in the root directory.

[X] Doc CPU

CHIadam · 06-07-2012, 04:13 PM

This box was from another office and that admin decided not to make a home partition. That explains it