[SOLVED] Partition full, but files make up only half partition size

Johng · 04-29-2022, 10:39 PM

I have a partition which gparted reports is 228GB with 1.5GB free

Using the Disk usage app in Linux Mint 20.3, the files total only 118.8GB, which I believe to be the true size.

Running e2fsck I get:

Code:

mint@mint:~$ sudo e2fsck -f /dev/sda2 
e2fsck 1.45.5 (07-Jan-2020)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda2: 631943/14942208 files (0.6% non-contiguous), 56405689/59767552 blocks

Where do I go from here?

syg00 · 04-29-2022, 11:01 PM

Start by showing relevant info. This will get us started.

Code:

df -hT
lsblk -f

Partitons ain't filesystems although they are inextricably inked.

Johng · 04-29-2022, 11:30 PM

Thank you syg00

Code:

chris@chris-H61M-USB3-B3:~$ df -hT
df: /run/user/1000/doc: Operation not permitted
Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  1.9G     0  1.9G   0% /dev
tmpfs          tmpfs     385M  1.4M  384M   1% /run
/dev/sda2      ext4      224G  211G  2.1G 100% /
tmpfs          tmpfs     1.9G     0  1.9G   0% /dev/shm
tmpfs          tmpfs     5.0M  4.0K  5.0M   1% /run/lock
tmpfs          tmpfs     1.9G     0  1.9G   0% /sys/fs/cgroup
tmpfs          tmpfs     385M   16K  385M   1% /run/user/1000
/dev/sdf1      vfat      1.9G   24M  1.9G   2% /media/chris/ADATA-2GB
chris@chris-H61M-USB3-B3:~$

Code:

chris@chris-H61M-USB3-B3:~$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 232.9G  0 disk 
├─sda2   8:2    0   228G  0 part /
└─sda3   8:3    0   4.9G  0 part [SWAP]
sdf      8:80   1   1.9G  0 disk 
└─sdf1   8:81   1   1.9G  0 part /media/chris/ADATA-2GB
sr0     11:0    1  1024M  0 rom  
chris@chris-H61M-USB3-B3:~$

pan64 · 04-30-2022, 01:17 AM

Code:

/dev/sda2      ext4      224G  211G  2.1G 100% /

It is full (obviously). That disk usage app might miss something, I don't really know, but df cannot lie.
You can use some tools to find out what is it, for example ncdu. But do it as root and without gui. Don't forget about hidden (dotted) files/dirs.

Johng · 04-30-2022, 01:53 AM

It is full (obviously). ??

Running ncdu:

Quote:

Total disk usage: 100.5 GiB Apparent size: 100.3 GiB Items: 118993

pan64 · 04-30-2022, 02:54 AM

yes, ncdu missed again some files. Most probably those hidden files. But without details hard to say more.

suramya · 04-30-2022, 03:15 AM

Or it could be that there is a large file that was created and deleted, but is still in use by some process. So while the file is marked as deleted it is still there on the filesystem using space till the process is terminated. I have seen this in the past and it was a pain to debug. One option is to reboot and see if the space is still being used.

Another thing to do is to perform a filesystem check on the partition. The simplest way to force fsck filesystem check on a root partition is to create an empty file called forcefsck in the partition's root directory and rebooting. It will force a check on the partition.

Johng · 04-30-2022, 03:34 AM

Quote:

yes, ncdu missed again some files. Most probably those hidden files. But without details hard to say more.

This is the ncdu output:

Quote:

100.5 GiB [##########] /home
7.7 GiB [ ] /usr
. 918.7 MiB [ ] /var
722.9 MiB [ ] /opt
310.7 MiB [ ] /boot
. 23.8 MiB [ ] /media
. 13.2 MiB [ ] /etc
. 1.4 MiB [ ] /run
. 64.0 KiB [ ] /tmp
! 16.0 KiB [ ] /lost+found
e 4.0 KiB [ ] /srv
! 4.0 KiB [ ] /root
e 4.0 KiB [ ] /mnt
e 4.0 KiB [ ] /cdrom
. 0.0 B [ ] /proc
. 0.0 B [ ] /sys
0.0 B [ ] /dev
@ 0.0 B [ ] libx32
@ 0.0 B [ ] lib64
@ 0.0 B [ ] lib32
@ 0.0 B [ ] sbin
@ 0.0 B [ ] lib
@ 0.0 B [ ] bin

Total disk usage: 110.2 GiB Apparent size: 109.8 GiB Items: 717576

It is hard to imagine there could be 100GB hidden files. It's an ext4 file system. How do we find them?

pan64 · 04-30-2022, 03:42 AM

Quote:

Originally Posted by Johng

This is the ncdu output:

It is hard to imagine there could be 100GB hidden files. It's an ext4 file system. How do we find them?

based on post #7 (if you have a file [or more] which is already deleted but still kept by a process) you only need to reboot.

Code:

ncdu -x /

should display everything on your root partition, which is not [yet] deleted.

Johng · 04-30-2022, 05:01 AM

Code:

ncdu -x /
 100.9 GiB [##########] /media                                                 
  100.5 GiB [######### ] /home
    7.7 GiB [          ] /usr
  927.6 MiB [          ] /var
  722.9 MiB [          ] /opt
  310.7 MiB [          ] /boot
   20.8 MiB [          ] /root
   13.3 MiB [          ] /etc
   88.0 KiB [          ] /tmp
e  16.0 KiB [          ] /lost+found
e   4.0 KiB [          ] /srv
e   4.0 KiB [          ] /mnt
e   4.0 KiB [          ] /cdrom
@   0.0   B [          ]  libx32
@   0.0   B [          ]  lib64
@   0.0   B [          ]  lib32
@   0.0   B [          ]  sbin
@   0.0   B [          ]  lib
@   0.0   B [          ]  bin
>   0.0   B [          ] /sys
>   0.0   B [          ] /run
>   0.0   B [          ] /proc
>   0.0   B [          ] /dev

 Total disk usage: 211.0 GiB  Apparent size: 210.6 GiB  Items: 635346

As shown above, the file in /media was the problem.

The computer is not mine. I now suspect the owner plugged in an external USB drive, and did not un-mount it!

Thank you for your help.

On an aside (breaking the rules) when an external drive is mounted at /media, does rsync treat the mount as a symlink?

pan64 · 04-30-2022, 05:08 AM

Quote:

Originally Posted by Johng

Code:

ncdu -x /
 100.9 GiB [##########] /media                                                 
  100.5 GiB [######### ] /home

 Total disk usage: 211.0 GiB  Apparent size: 210.6 GiB  Items: 635346

As shown above, the file in /media was the problem.

it looks like.

Quote:

Originally Posted by Johng

The computer is not mine. I now suspect the owner plugged in an external USB drive, and did not un-mount it!

No, it looks like the owner copied files into /media on the local disk instead of mounting USB and copying files onto that usb stick.

Quote:

Originally Posted by Johng

On an aside (breaking the rules) when an external drive is mounted at /media, does rsync treat the mount as a symlink?

rsync or any other tool has no any idea what is really located at /media (If it was a local dir, a mount point or whatever), it will just use that.

uteck · 04-30-2022, 03:04 PM

If I remember correctly, when a USB drive is automounted it creates a new directory in /media with the users name, and then makes another in that with the device name.
So it does seem that files were copied into /media and took up space on the drive.

computersavvy · 04-30-2022, 06:54 PM

Remember one thing about directories that are used as mount points. If files are in that directory then something is mounted on that directory / mount point, the content is hidden and inaccessible even though it takes up space on the file system.

Except in rare cases and done deliberately a user should not put content into a directory used as a mount point. Especially a user should avoid /mnt, /media and /run/media since those are often used mount points.

pan64 · 05-01-2022, 02:09 AM

Quote:

Originally Posted by computersavvy

Remember one thing about directories that are used as mount points. If files are in that directory then something is mounted on that directory / mount point, the content is hidden and inaccessible even though it takes up space on the file system.

Except in rare cases and done deliberately a user should not put content into a directory used as a mount point. Especially a user should avoid /mnt, /media and /run/media since those are often used mount points.

That is the typical case, when you have no idea if /media is mounted or not. So you will copy a lot of files onto it and surprisingly they cannot be found on the usb.
But next time you mount it successfully you will not find it in /media too (because as you wrote the local content is hidden).