# what is /proc/kcore and why is it taking up 1.2GB!!

## butters

I was wondering why /proc was taking up 1.2GB on my hard disk, and I found that the very vast majority was due to a single binary file, /proc/kcore.  What is this file used for and why is it so big?  Is this a normal size for kcore?

----------

## desultory

```
He's not fat, he's my core dump.
```

From /usr/src/linux/Documentation/filesystems/proc.txt.

 *Quote:*   

> kcore       Kernel core image (can be ELF or A.OUT(deprecated in 2.4))   

 

----------

## troymc

Don't worry about anything in /proc. It's a virtual filesystem and is not taking up any disk space.

/proc/kcore should be the size of your memory. It is a gateway to your physical memory. If you read from it, you are reading directly from your physical memory.

troymc

----------

## hampelratte

i have the same problem since i have upgraded my ram to 1.5gb 

```
$ df -h

Dateisystem          Größe Benut  Verf Ben% Eingehängt auf

/dev/hda2             950M  902M     0 100% /

```

as you can see, my root partition has no space left because of kcore. at least some programs think so, for example firefox, when trying to download things to /tmp. that is very annoying. is there a workaround for that problem? can i disable this function in my kernel config?

otherwise i would have to repartition my harddisk, which i want to avoid.

thanks

henrik

----------

## hampelratte

found the answer by myself. there is an option for /proc/kcore in the kernel config. i have disabled this function now and will hopefully not run into this problem again.

----------

## Stever

As previously explained, /proc does not exist on your harddrive, and turning off /proc/kcore support will not free disk space.

Try 

```
# df -ah
```

 to see what I mean - /proc is a separate mount from your hd.

----------

## i92guboj

 *hampelratte wrote:*   

> i have the same problem since i have upgraded my ram to 1.5gb 
> 
> ```
> $ df -h
> 
> ...

 

Please, read above. 

Anything in /proc is not taking any amount of disk space at all. /proc is just an interface to your live kernel, and not a physical filesystem in your hard drive. If your / is full, it is not because of kcore not anything under /proc.

----------

## hampelratte

yes, i know that proc is virtual, but as i explained, for some programs it looks like there is no space left on the device because kcore is included in the calculation of disk usage, though there is enough space left on the device. if i du over all directories, which live on / excluding kcore the sum shows the right value of free disk space.

----------

## i92guboj

 *hampelratte wrote:*   

> yes, i know that proc is virtual, but as i explained, for some programs it looks like there is no space left on the device because kcore is included in the calculation of disk usage, though there is enough space left on the device. if i du over all directories, which live on / excluding kcore the sum shows the right value of free disk space.

 

No. At least, that would not be a normal behaviour.

/proc is mounted as another filesystem, and as such, its size should not interfere in the rest of partitions. When you do a df -ah you can see the space used and available for each mounted volume, including /proc. Each volume is a separate entity, and the space that /proc/kcore takes should, by no means, interfere with the root partition, the same that /usr or /var don't do so either.

Can you confirm that that space is being counted as used in the root partition or is it just an assumption? If you can really confirm it, then, in that case that would be a bug, though I am not quite sure where to dig first to find it.

Maybe firefox or the others complained for any other reason. Just maybe.

----------

## eccerr0r

I've found that a 1GB partition is really insufficient to install Gentoo, especially with portage on the same disk.

Make sure /usr/portage is somewhere that has a lot of space to grow, that tree itself takes quite a bit of disk space, coupled with /sbin, etc., will quickly eat up a root partition.  You don't detail enough of the partitioning scheme so this is just an assumption and it sounds like you did not preplan partitions (?)...

I was trying to get a 2GB disk install with firefox, that was pretty much impossible to do if I had portage on the same disk...

----------

## hampelratte

i planned my partition scheme very well except /tmp which should have been on another partition

```
# df -h

Dateisystem          Größe Benut  Verf Ben% Eingehängt auf

/dev/hda2             950M  280M  622M  32% /

udev                  760M  2,7M  757M   1% /dev

cachedir              950M  280M  622M  32% /lib/splash/cache

none                  760M     0  760M   0% /dev/shm

/dev/hda5             9,2G  5,7G  3,1G  65% /var

/dev/hda3             9,2G  5,7G  3,1G  65% /usr

/dev/hdc3             3,0G  1,3G  1,6G  46% /opt

/dev/hdc2             2,0G  1,8G   72M  97% /home

/dev/hda1             4,7G  3,9G  851M  83% /mnt/win

/dev/hda6              41G   35G  5,6G  87% /mnt/programme

/dev/hdc4             109G   84G   26G  77% /mnt/daten

/dev/hda7              84G   60G   20G  76% /mnt/dachboden
```

as you can see my / only takes 280M and there is 620M left for mainly /tmp, which is enough in most cases. 

i figured out the problem: it was firefox in combination with mplayerplug-in. the mplayerplug-in stored a big movie in a temp file in /tmp. after closing the mplayerplug-in tab in firefox the file has been deleted but somehow not really. lsof +L1 still showed this file as (deleted) and tools like ls and du seemed to ignore this file. df included the file for it's calculation. that's why i thought kcore was the bad guy, because kcore was the only big file in /. after closing firefox at all, everything looked fine again. so be careful using the mpalyerplug-in  :Wink: 

----------

## Roman_Gruber

interesting thread   :Cool: 

----------

