Proc folder using too much of Drive space

I have a 491GB drive my OS is installed on, 249GB used 217GB free but only a small portion is used for all but the proc/process folder (see attached images). If I open properties for proc folder it shows impossible 140TB usage. To my understanding this impossible number is normal, seems weird but I can accept that. What I can’t accept is that if I do the math (other folders usage vs drive space usage) my proc folder still seems to use almost 180GB of drive space. How is this possible? How can I fix it?

I would post screenshots but as new user to the forum they won’t allow it yet.
Note: I have posted in past but forgot user login info so started over lol…

/proc is not a normal folder.

It represents the running system, so any storage information you get from it will be inaccurate.

1 Like

Ok so what should I do about the 188GB of unexplained usage when I don’t look at that proc folder? What I mean is if I highlight all but the proc folder and click properties I only have 61GB out of the 249gb claimed used.

Welcome to the forum. :slight_smile:

I’m afraid you are completely mistaken ─ it’s an understandable mistake, though, and you are not the only one to make it. :wink:

/proc is a virtual filesystem. Its contents are not on your drive. /proc is an interface through which applications can interact with the kernel by way of an abstraction layer in the form of a hierarchy of files and directories.

The sizes of the (pseudo-)files in /proc are also not to be taken literally, as it usually pertains to virtual memory. Virtual memory means that the sizes you see for those objects represent the sizes of the address space that has been reserved for use by any given process, not the actual amount of memory being used by said process. :wink:

A better way to see the info you intended to see is to execute df,
You can ignore anything that has tmpfs in it’s name on left, because they are not physical storages…

Actually, they are, but their contents live in virtual memory. In practice, this usually means “in RAM”, but unlike with a regular ramfs, the contents of tmpfs can be paged to swap storage if needed. :wink:

/proc and /sys however are both virtual as a whole.

The only reason I discovered this issue was I was going to attempt to install a debian distro along side my arch distro and the debian distro showed way less storage available then I expected. With that if I do the df command in terminal it still shows 232GB of my main drive used… Those numbers I gave are close enough to accurate to be fairly confident the proc folder is somehow soaking up a ton of drive space for some crazy reason. Maybe I’m wrong though, I’m no expert lol BTW i don’t use any swap (its not even partitioned) as I have 48GB of ram that I often closely fill up but I’ll upgrade that soon.

But it’s not. /proc doesn’t contain any actual files, and its contents do not exist on your drive. The same is true for /sys.

Also, as noted by @TriMoon and myself, the contents of anything you see as tmpfs in the df output do not exist on your drive either, but instead they reside in virtual memory. So if anything is filling up your drive, then that must by definition be something else.

Well that is interesting then how do I figure out this false fill? I am working on some other issues now. I have been using this os for almost 2 years now with minimal issues so I’m due for some trouble. Just found out I no longer know my root password so now I am working to reset that so I can figure this issue out. I always though su and sudo were the same but I guess not? I can do su in terminal with my password I remembered but not sudo, IDK how I butchered it so bad meh. Normally when I get into this much of a issue I just start over but I like the way I have it laid out and working so would rather not do that lol. Besides I need to figure out the correct way to do things for once and not just hit reset on the works. I have been full time linux long enough that I’m due to get more in depth. Perhaps I should take a spare PC and start to attempt installing raw arch system so I can better understand things after failing over and over…

du can show you the amount of space used per directory ─ see the man page for details, because without the correct options, the output can be quite overwhelming. But we don’t know how you’ve partitioned your drive, what software you’ve added, whether you use any Snap or FlatPak packages, and so on.

You may also want to clean out /var/cache/pacman/pkg. Installed packages ─ and possibly uninstalled packages too ─ are stored there, and if you don’t clean out that cache on a regular basis, then that could grow to substantial proportions. See… :arrow_down:

man paccache

… for details. If you want to completely empty the package cache, issue… :arrow_down:

sudo paccache -rvk0

su and sudo are definitely not the same thing, but while sudo is usually set up to require the user’s own password, su by default requires the target user’s password, which means the root password if no other account was supplied as a target.

Therefore, it would be illogical that you can still use su but not sudo, and I suspect you’ve got that backwards. Either way, just issue the command… :arrow_down:

sudo su -

… to become root, and then you can set a new root password with the command… :arrow_down:

passwd

Hitting the reset button is asking for trouble, and it may be one of the reasons why you’ve got inconsistencies in the reported disk space ─ your filesystem could be damaged.

By hitting reset I mean completely start over and install OS from scratch with new format and all. Then I would at least have correct root password and back to less disk space used. I cant “sudo su -” because my password is incorrect for who knows what reason. In other words I am unable to become root. I did clear out a bunch of old repositories and what what not before this post. I also just attempted a chroot process from boot usb but started to ? it due to my lack of experience and stopped before I could really change anything. While I was in live usb I checked the folders usage from gui and it showed nothing in the proc like it should and all folders used only 46GB but when I check properties of the drive it still has 249GB used. Could it maybe be hidden folders? I never did check that.

Those will only exist within the users’ home directories, and they only contain configuration data and cache. So that’s not going to be eating up your disk space. :man_shrugging:

1 Like

I didn’t think so either, hmm well thanks anyway I may just do a reset of the system after all, screw it. Wish I had more time to play but this day is coming to an end and I have work to do tomorrow. Some day I will have time to learn the ins and outs of the Linux system from a terminal level. Thanks for all the help:)

1 Like

The diff between Debian and Manjaro wrt sudo is that Manjaro needs the user to be in the wheel group instead of the sudo group…
If you are able to run su - you should be able to change the root password :wink:

Include dummy file systems: df -a
Also check out the find command to find files greater than X size. For example,

find $HOME -size +1G -ls
find / \( -path /proc -o -path /sys -o -path /dev \) -a -prune -o -size +1G -ls

Take a glance at the temp directory, the log directory (journalctl --disk-usage) and core dumps (coredumpctl).

1 Like