'kcore' file on memory device /proc is 128 Tb (140,737,477,885,952 bytes) in size

When I attempted to run a 2005 era application with current (2017) versions of required library files, a number of faults occurred that pushed the ‘kcore’ file to some technical size limit. This is on a 41Gb disk partition. Once the file had grown larger than 41 Gb, without process space, running any app became very sluggish, then disk full warnings were presented. Rebooting was not a problem. Without process space no graphical interface could run. CLI work great. I noted that my run-away app survived a warm and cold reboot and continued to clock up the file size to 128Tb within a few minutes. Also no tools could kill the app’s process, as no process space was available. Lack of tool response occurred before and after multiple reboots. Using recovery boot image provided no relief. Note that Leap 42.3 was up-to-date with all patches available at the time.

Eventually I reinstalled Leap from DVD - no issues everything works great. I Have not applied any updates to the May 2017 42.3 image since I do not have network access to this system at this time. The Yast re-install was over the old partition and swap partition with a format.
My home directory and user files are on a separate partition. The re-install pulled over these identities. So user space is the same. I did delete the library files that the 2005 app was still attempting to load from /usr/local that also survived the format. This stopped all error messages and related processes. I also deleted any cache files in hidden directories. This also told me that the partition format is a ‘quick’ read if no errors, and not a true format.

Currently I can run any application or tools successfully. These were tests after I noted after that the ‘/proc/kcore’ file is still noted as 128 Tb in size. The only difference is the 41 Gb disk after re-install now shows 29.2 Gb free.

If I note any odd behavior or operational issues I will delete the disk partitions and recreate them with a format, then re-install Leap. Maybe this will force the /proc memory device to respond to physical disk space.

My questions are: 1) how did the memory device /proc/kcore file size survive format? I ran older image snapshots successfully before the re-install and the file size error was still present within any snapshot image booted. 2) How can I return kcore to respond to the actual free disk size behavior?

/proc doesn’t exist on your hard disk.
It’s an interface to kernel internals, i.e. its content is “created”/managed dynamically.

IIANM kcore “contains” all the addressable virtual memory, which is 128TiB on a 64bit system.

See also https://en.wikipedia.org/wiki/Procfs

Thank you for your response.
I agree that /proc does not exist. In the kernel.org documentation it is referred to as a ‘memory device’. There is a very large listing of these.

After looking at another system the /proc is also very large. So your implied answer is correct, /proc has no bearing on the problem.

From my other comments in my original post I suspect information is somehow surviving the format. As the amount of time it takes to format a partition is not long, it cannot be a low-level format. I have seen this happen in the past. Strange and very rare, but it does happen.
So I will totally delete the partition. Then power off the computer to ensure some memory map is not the surviving entity that is causing the system to belief it does not have any free disk space. Both of these problems were quite common 20+ years ago.

Then I will create a new partition, power off. Then do another new clean Leap installation. Time consuming but I am just looking to get some other work done. My first clean re-installation should have cleared up the issue. Worst case is this next rebuild fails. Then hardware could be the cause. I’ve seen this to. I hope not.

Thank you again for reminding me to look at a correctly operating system to see that the normal behavior of /proc is to have a really large size number.
I will post an update after I do another re-install following the above procedure.

No, it is not a low-level format (AFAIK such a thing is not even possible hardware-wise since a long time, i.e. decades), nor does it wipe out all blocks on the disk.

It just creates the filesystem from scratch.
But no filesystem “information” can survive that, not even in “hidden” directories. (of course you may still be able to recover some data by reading the disk blocks directly)

I’m not sure I understand what your actual problem is.

Maybe you actually did not format the root partition?
Or maybe you have some things (like /usr/local/) on a separate partition that you didn’t format.

Although, you write in the first post “The only difference is the 41 Gb disk after re-install now shows 29.2 Gb free.”, which would sound about right.
So I can assume you don’t actually have a problem (anymore)?