Deleted files did not free up disk space

sofasurfer

Active Member
Joined
May 24, 2022
Messages
168
Reaction score
58
Credits
1,425
I have Ubuntu 20.04 with 1tb drive. /home is on a seperate partition and / is on its own 53.91 gig partition with 43.67 gig used. Computer runs slow. I start it and when the desktop loads I see the icons jump out to the desktop. Other functions are slow also. I went into /boot/grml and deleted a ubuntu 22.04 iso and a ubuntu 20.04 iso. The amount of used space did not change. Why not? What else should I be looking for that will cause the slow down?
I have 8gig of memory.
 
Last edited:


Rather than find what else will cause the slow down and the proceed to delete it......why not use GParted to expand the size of the /home ?....Just a thought.
Also the / partition is approx 81% full...it needs more space to function easily

GParted can serve you well there as well.

I would enlarge both partitions, and then (if necessary) look elsewhere

The two files you deleted are only using approx 3gb.....maybe a bit more....that may take a while to show....possibly a reboot ?

Edit to add: 1gig drive....should that be a 1TB drive ?
 
What did you use to measure disk space. Perhaps try these in a terminal:
Code:
df -h
lsblk

Sometimes the journal can be unexpectedly large. To check the space the journal is taking, you can run:
Code:
du -sh /var/log/journal
 
Rather than find what else will cause the slow down and the proceed to delete it......why not use GParted to expand the size of the /home ?....Just a thought.
Also the / partition is approx 81% full...it needs more space to function easily

GParted can serve you well there as well.

I would enlarge both partitions, and then (if necessary) look elsewhere

The two files you deleted are only using approx 3gb.....maybe a bit more....that may take a while to show....possibly a reboot ?

Edit to add: 1gig drive....should that be a 1TB drive ?
You are wise o master. I changed it to 1 tb. Oops!
I hesitate to change part size as it has failed in years gone by but I keep good backups now so I probably will enlarge the / part. You are probably correct that I need to delete a larger pile before it shows up on a 1tb drive.
 
What did you use to measure disk space. Perhaps try these in a terminal:
Code:
df -h
lsblk

Sometimes the journal can be unexpectedly large. To check the space the journal is taking, you can run:
Code:
du -sh /var/log/journal
I hear you friend, but I have no clue (after all these years) what "journal" is. All I work with is bytes.
 
the 'Journal basically stores log files.

Sometimes, it gets out of control and fills up rapidly.
Mine shows the below...

brian@brian-desktop:~$ du -sh /var/log/journal
143M /var/log/journal
brian@brian-desktop:~$

That means it occupies just 143 Mb....which is fine

and....
df -h
lsblk

shows.....

tmpfs 3.2G 1.7M 3.2G 1% /run
/dev/nvme0n1p2 228G 27G 190G 13% / .......MAIN DRIVE with LM21.2
tmpfs 16G 34M 16G 1% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 16G 0 16G 0% /run/qemu
/dev/nvme0n1p1 511M 13M 499M 3% /boot/efi
tmpfs 3.2G 104K 3.2G 1% /run/user/1000
/dev/sdc1 920G 221G 653G 26% /media/brian/TV, Timesh
/dev/sdc3 649G 29G 621G 5% /media/brian/Important stuff
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 111.8G 0 disk
├─sda1 8:1 0 286M 0 part
├─sda2 8:2 0 8.2G 0 part
└─sda3 8:3 0 103.3G 0 part
sdb 8:16 0 279.5G 0 disk
└─sdb1 8:17 0 279.5G 0 part
sdc 8:32 0 1.8T 0 disk
├─sdc1 8:33 0 935.2G 0 part /media/brian/TV, Timesh
├─sdc2 8:34 0 279.4G 0 part
└─sdc3 8:35 0 648.4G 0 part /media/brian/Important stuff
nvme0n1 259:0 0 232.9G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
└─nvme0n1p2 259:2 0 232.4G 0 part /
brian@brian-desktop:~$
 
Last edited:
I hear you friend, but I have no clue (after all these years) what "journal" is. All I work with is bytes.
Okay :)

The first two commands which I suggested will provide the space used on your filesystem and need to be run in a terminal where they output readable sizes. Here is an example from this machine:
Code:
[tom@min ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            7.7G     0  7.7G   0% /dev
tmpfs           1.6G  1.9M  1.6G   1% /run
/dev/nvme0n1p3  443G   14G  406G   4% /
tmpfs           7.7G     0  7.7G   0% /dev/shm
tmpfs           5.0M   12K  5.0M   1% /run/lock
efivarfs        192K   99K   89K  53% /sys/firmware/efi/efivars
/dev/nvme0n1p1  476M  5.9M  470M   2% /boot/efi
tmpfs           1.6G   60K  1.6G   1% /run/user/1000


[tom@min ~]$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sr0          11:0    1  1024M  0 rom
nvme0n1     259:0    0 465.8G  0 disk
├─nvme0n1p1 259:1    0   476M  0 part /boot/efi
├─nvme0n1p2 259:2    0  14.9G  0 part [SWAP]
└─nvme0n1p3 259:3    0 450.4G  0 part /

The sizes are quite clear, and after each deletion one makes of a file, the outputs of these commands will show a difference in size and percentage, that is, if the deletions are not simply too small, like in a few kilobytes. The outputs of both commands can be compared and should approximate each other.

The journal is a record of the working of the system basically run by the kernel and creates a record of what is happening and writes that to a log file. The log file's size is configured in a file at /etc/systemd/journald.conf which can control that size. Sometimes the journal can run out to many gigabytes, but we don't know how big it is in your case until we check it out to see if it's useful to trim it.
 
Deleting is not the same as uninstalling. Until the area where the file(s) reside have been over written they are still available to be accessed. Albeit dangerous for one who is not computer savvy wiping a drive or files can insure the data is no longer available. I however do not recommend this option unless one is absolutely sure they know what they are doing.
Always,
Wildman
 
I'll never know why some people have Home and Root on separate partitions...I don't and have no problems.
m1213.gif

Albeit dangerous for one who is not computer savvy wiping a drive or files can insure the data is no longer available. I however do not recommend this option unless one is absolutely sure they know what they are doing.

A very good point...beginners shouldn't be deleting anything and I bet the OP doesn't have a backup either.
m1512.gif
 
It's worth clarifying the effect of deletion and uninstalling in order to realise that the deletion of files, as well as the uninstallation of packages, can both create space in the filesystem, and that the space created through both approaches then becomes available for the user to use for the creation of other files, or other installed packages.

In the case of uninstalling packages, it's clear that the space on the filesystem will become available to the user since that's what the package manager does, and in the case of removal of packages with apt, it will inform the user on screen of how much space will become available again.

In the case of the removal of files, space will also be created for the user to use for use either for the further writing of files or for the installation of packages.

In this example, the file of kernel 6.7 source code was downloaded from kernel.org and the command: df -h, was used to output the size of the available space on the filesystem to show that the deletion of files (by the rm command) makes space available for the user.

Before downloading the kernel 6.7 compressed file, there is 406G available on this filesystem:
Code:
[tom@min ~] df -h
Filesystem      Size  Used Avail Use% Mounted on
<snip>
/dev/nvme0n1p3  443G   15G  406G   4% /
<snip>

Once the kernel has been downloaded and decompressed, it takes up around 1.5G of space:

Code:
[tom@min ~/src/kernel]$ du -sh linux-6.7
1.5G    linux-6.7

The output of the df command now shows that the available space on the filesystem has been reduced to 404G:

Code:
[tom@min ~] df -h
Filesystem      Size  Used Avail Use% Mounted on
<snip>
/dev/nvme0n1p3  443G   17G  404G   4% /
<snip>

Upon deletion of the kernel and all the files and directories it created upon it's decompression, the available space on the filesystem has returned to 406G

Code:
[tom@min ~] df -h
Filesystem      Size  Used Avail Use% Mounted on
<snip>
/dev/nvme0n1p3  443G   15G  406G   4% /
<snip>

It's clear that the deletion of files creates space on the filesystem.

In relation to the assertion: "Until the area where the file(s) reside have been over written they are still available to be accessed.", this is the case, but it's immaterial in relation to size of the space made available to the user after the deletion of the files. That space, despite the old data still on the disk, nevertheless becomes available for the user to use. The fact that the data still sits on the disk until overwritten by the operating system is a function of the way in which files are removed, which is by having their metadata removed or neutralised so that the filesystem no longer sees the files since it needs the metadata to refer to and identify those files. Since this is the way in which removal of files happens, (by neutralising the metadata) the actual data of the files stays in place. Because that's the case, it's possible with specialised tools to access file data even without the metadata being the guide, so long as that data hasn't been overwritten. But if new files are written by the user, that space with the old data, is available for the user as space, as shown in the above example. It's not the case that such space with old data is not counted as space available for the filesystem to use.

The upshot is that, the removal of large files creates space, so identifying such files and assessing whether they can usefully be removed, can be useful in situations where there are problems with space.
 
Last edited:
I have Ubuntu 20.04 with 1tb drive. /home is on a seperate partition and / is on its own 53.91 gig partition with 43.67 gig used. Computer runs slow. I start it and when the desktop loads I see the icons jump out to the desktop. Other functions are slow also. I went into /boot/grml and deleted a ubuntu 22.04 iso and a ubuntu 20.04 iso. The amount of used space did not change. Why not? What else should I be looking for that will cause the slow down?
I have 8gig of memory.
Just a thought, check the Trash bin. Deleting the ISOs may have just moved them to Trash. May need to empty trash to see the size difference.
 
The amount of used space did not change. Why not? What else should I be looking for that will cause the slow down?
I have 8gig of memory.

If you run top, is there anything hogging up RAM and CPU?
Does it do this after you've rebooted the system?

It has been mentioned before, that sometimes processes hold file handles open.
For example if I have tcpdump writing to file, and then in another console, I try to delete that file.
It was say the file is deleted in that console, but in the original console the file is still growing.

Also, file writes and deletes are not always immediate. This is why there is a eject or safely remove drive button.
Even though your file manager shows the file was copied or deleted immediately, it's really cached in RAM, and
it your turn off your computer before the cache really writes the file to your USB, it won't be there.
The same can happen on hard drives.
 
Since when does Linux fill up with system file crap...it's not windoze.
t9403.gif


I have Mint on a 500GB SSD and is only 38% full...log files are 1.8GB which is nothing. I have a 50GB VM which again is nothing on a 500GB Drive and doesn't slow down either...it's all in the setup.
2024-01-09-12-59.png

You should at all times have at least 20% of free space so everything on the Drive can run efficiently.
m1212.gif
 
My problem was trash in the trash bin at admin:///root/.local/share/trash
I had the same problem, after deleting a 30gb folder it just disappeared and didn't show up in the trash bin, I knew for sure that I had more free space than what's shown on the file manager.
 

Staff online

Members online


Top