/proc is huge!

[Richard]

Thunar indicates that /proc contains 140.7 TB, while DoubleCommander shows 131071.99 GiB.

If you have ever noticed this and wondered what the explanation might be, the following provides a possible answer.

I thought this was unusual and figured there must be a good reason/answer for it.
Today I decided to search for it, which produced references to a possible answer in the LinuxMint forum:

Re: Why is the size of /proc 140 TB? (SOLVED)
Post by Cosmo. » Sun Aug 23, 2015 5:25 am

The "biggest file" (in quotation marks, because those files are not really there) is kcore, which "takes" nearly the whole amount of /proc.

Looking for an answer how this is explainable I found at first this in unixguide, but that doesn't seem to be right, because

/proc/kcore is like an "alias" for the memory in your computer. Its
size is the same as the amount of RAM you have, and if you read it as
a file, the kernel does memory reads.

would mean I would have 140 TiB RAM (does any super-computer have this amount?)

The answer here at askubuntu seems to be the correct answer:

This file ... is as big as the address space that Linux could potentually address at max.

Well, maybe, sort of; however, supposedly the 64 bit memory limit is 128 Terrabytes.
Perhaps it's just a problem of scale with Thunar, DoubleCmd and other file managers?

Code: Select all

richard@mx171:/proc
$ df -h /proc
Filesystem      Size  Used Avail Use% Mounted on
proc               0     0     0    - /proc

Does anyone have another, better explanation?

[Gordon Cooper]

I have met up with bytes "rounding up to" elsewhere, happens a bit in GParted, but never struck anything even approaching 140 TB!

[antiX-Dave]

I try with spacefm / du and they both report 0 as the amount of disk space used... though kcore shows a "size" of 128 tb for the file but the size on disk is still 0.

I have never really thought about it... My *guess* based on that and what you posted would be that the size counting method is seeing the limit of what you *could* virtually have for ram. As in what soft limit the kernel has set given the way the kernel handles memory and the type of hardware you have. Even though you could not physically add that much memory to your machine. And I would further guess that even though you may have a 64 bit machine a smaller amount of bits are actually used (say 47 bits) which might vary from machine to machine (47 on one 41 on another) allotting for the variations in outputed size readings.

[Richard]

It was a surprise to me also.
I was sure I'd broken something. :)

I believe it's just a quirk of file managers.
Probably they are all using the same type of algorithm.
Except 'df' which shows the correct size.
NOTE: and SpaceFM, du...

[Adrian]

Yes, that's the explanation, it's a virtual memory addressable space.
I think it's 128TiB (Tebibytes) which is 140 TB (Terabytes).

BTW, 131071.99 GiB = 128 TiB (rounded of course)

[stsoh]

what is kcore(140tb)?
google kcore, u will find explanation as:
/proc/kcore specifically is a file which maps directly to every available byte in your virtual memory.

[Eadwine Rose]

I don't even have a /proc/kcore on my system, but the proc thing is indeed loads of TB

[stsoh]

no kcore then find out where is 140tb from?

[Eadwine Rose]

I don't know.

[Adrian]

https://unix.stackexchange.com/question ... e-by-linux

Also if you take a look at the kernel docs, Documentation/x86/x86_64/mm.txt:

Virtual memory map with 4 level page tables:

0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm
So 2^47 bytes = 128TiB

And 128TiB = 140TB, so there's that.