[solved] Wrong free space after repairing EXT4 fs with Gnome Disks

Strangiato · 2025-06-06 21:42:46

Hello

I have a 2 TB (1.82 TiB = 1863 GiB) hard disk with 1 ext4 partition only used to store personal files, I have Arch with KDE Plasma DE and Windows 10 installed, and I use Paragon EXT driver to read/write to ext4 on Windows 10. I copied some GiB of data to ext4 fs while using Windows 10, but when rebooting and then using Arch the copied data was missing (because I forgot to manually unmount the ext4 partition on Win10 before rebooting). Then I repaired the ext4 partition on Arch using Gnome Disks. Apparently the ext4 file system was successfully repaired, but now the data copied to ext4 fs while running Windows 10 is still missing and the space correspondent to it is still occupied.

Now "du" command reports that the mount point of the ext4 partition uses 1884735661621 bytes (1755 GiB of 1863 GiB in total), but the file manager (Dolphin) only reports 1.8 GiB of free space.
How to get the real free space back?

Thanks for reading.

Last edited by Strangiato (Yesterday 15:40:21)

seth · Yesterday 06:50:17

https://wiki.archlinux.org/title/Ext4#Reserved_blocks - 93.15GB are reserved by default, so a 14.85GB gap?
Did you run du as root (it might not be able to stat some files otherwise) - also be careful w/ your mix of SI and actual sizes, check "df -B1"

df -B1
sudo df -bs /path/to/mount
sudo tune2fs -l /dev/sdXn

Strangiato · Yesterday 12:29:10

Reserved blocks is set to 0%

$ sudo tune2fs -l /dev/sdb2 | grep 'Reserved block count:'
[sudo] password for myuser: 
Reserved block count:     0

du, now as root:

$ sudo du -B1 --total /mnt/2TB/
...
1965939662848   /mnt/2TB/
1965939662848   total

Last edited by Strangiato (Yesterday 12:30:33)

seth · Yesterday 12:48:44

So 1831 GactualB, now let's see what df -bs and tunefs -l consider free and allocated

Strangiato · Yesterday 12:59:09

$ sudo df -Bs /dev/sdb2
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb2       2,0T  2,0T  1,9G 100% /mnt/2TB

$ sudo tune2fs -l /dev/sdb2
tune2fs 1.47.2 (1-Jan-2025)
Filesystem volume name:   2TB
Last mounted on:          /mnt/2TB
Filesystem UUID:          cb0035ef-a728-41d3-87db-fe0bae21d9c9
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index orphan_file filetype needs_recovery extent 64bit flex_bg metadata_csum_seed sparse_super large_file huge_file dir_nlink extra_isize metadata_csum orphan_present
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              122101760
Block count:              488378368
Reserved block count:     0
Overhead clusters:        7945031
Free blocks:              467085
Free inodes:              121986899
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      909
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Thu Dec  7 22:22:53 2023
Last mount time:          Sat Jun  7 09:21:53 2025
Last write time:          Sat Jun  7 09:21:53 2025
Mount count:              3
Maximum mount count:      -1
Last checked:             Fri Jun  6 17:51:37 2025
Check interval:           0 (<none>)
Lifetime writes:          4774 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      4a406e60-8438-44c3-95b0-3f66b4c2628d
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x31b12d38
Checksum seed:            0xa8099f80
Orphan file inode:        12

seth · Yesterday 13:23:18

Sorry, I'm tired…

df -B1

"-bs" if for du

But

Block count:              488378368
Overhead clusters:        7945031
Free blocks:              467085

((488378368-7945031-467085)*4096-1965939662848)/1024^2
= 2.0078 MB

so this actually checks out (the overhead clusters are transactional data of the filesystem, don't ask me for the 2MB, they're probably used for something)
Depending on the data and whether you're willing to reformat the disk you could increase the block size what would (should™) reduce the overhead.

Edit:are you sure the data you wrote on windows is missing and not just hidden/somewhere else?

Last edited by seth (Yesterday 13:23:54)

Strangiato · Yesterday 13:28:33

$ sudo df -B1 /dev/sdb2
Filesystem         1B-blocks          Used  Available Use% Mounted on
/dev/sdb2      1967854948352 1965941768192 1896402944 100% /mnt/2TB

seth · Yesterday 13:36:47

There 1967854948352 bytes on that partition 1965941768192 are used - those are ~1832.7GB and ~1830.9GB and it matches the du findings.
There're really no irregularities here

Strangiato · Yesterday 13:54:38

seth wrote:

Edit:are you sure the data you wrote on windows is missing and not just hidden/somewhere else?

I'm sure. I had already checked before creating this topic, and I have checked again right now.
Before using paragon ext4 driver a few times on Windows10 this drive had ~90 GiB of free space according to Dolphin file manager. After copying data on Windows10 3 times now it currently has 15 GiB of data copied while using Windows10 and other ~75 GiB of free space has just disappeared.

This drive was previously formatted with ntfs fs. Then I reformatted it with ext4 fs because currently linux is my main OS, and also due to problems with ntfs-3g (bad performance and high cpu usage during data transfers) and ntfs3 drivers (fs corruption after deleting folders containing hundreds or thousands of files). Now even native ext4 is problematic.

Six months ago I had a unfixable error with my main drive also formatted with ext4:
https://bbs.archlinux.org/viewtopic.php?pid=2211623

Unfortunately linux still has bizarre and hard to explain problems.

Last edited by Strangiato (Yesterday 13:59:28)

seth · Yesterday 14:09:25

What "problems"?
You've a ~1833GB partition, ~1831GB of those are in use, ~2GB are free
If you want to see where the data is spent: https://archlinux.org/packages/extra/x86_64/ncdu/
To find all files modified since thursday (adjust the date accordingly)

sudo find / -newermt 2025-06-05

If you want to share data between OS, try exFat or FAT and it is SUPER-IMPORTANT to NOT

forgot to manually unmount the ext4 partition on Win10 before rebooting)

Also 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

If you're opening the FS (regardless of extFS, NTFS, FATisnotanFS) from two OS at the same time, you run into trouble - that's not a problem w/ any filesystem.

Edit: since you mentioned gnome disks

fdisk -l

Last edited by seth (Yesterday 14:10:16)

Strangiato · Yesterday 14:26:07

What "problems"?

~75 GiB of free space has disappeared from 2 TB drive; unfixable error with ext4 on my main drive.

FAT is unusable with files larger than 4 GiB, and I have lots of them. I already use exfat with a usb drive, I have never used it with an internal drive.

Windows fast-start is disabled since always on my Win10.

Last edited by Strangiato (Yesterday 14:46:18)

seth · Yesterday 14:30:11

~75 GiB of free space has disappeared from 2 TB drive

Where?
You've not posted anything suggesting data not being accounted for.

lsblk -f
df -h
fdisk -l

Post all of that, no greps.

Strangiato · Yesterday 14:52:03

$ sudo fdisk -l
Disk /dev/sda: 953,87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: Asgard AS1TS3-S7
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb72af171

Device     Boot      Start        End   Sectors   Size Id Type
/dev/sda1             2048  734005247 734003200   350G 83 Linux
/dev/sda2  *     734005248 1048578047 314572800   150G  7 HPFS/NTFS/exFAT
/dev/sda3       1048578048 2000409263 951831216 453,9G 83 Linux


Disk /dev/sdb: 1,82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: ST2000DM006-2DM1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x0f967ca5

Device     Boot Start        End    Sectors  Size Id Type
/dev/sdb2        2048 3907028991 3907026944  1,8T 83 Linux


Disk /dev/sdc: 223,57 GiB, 240057409536 bytes, 468862128 sectors
Disk model: GIGABYTE GP-GSTF
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x49035b2d

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sdc1            2048 146802687 146800640   70G 83 Linux
/dev/sdc2       146802688 293603327 146800640   70G 83 Linux
/dev/sdc3       293603328 468860927 175257600 83,6G  7 HPFS/NTFS/exFAT


Disk /dev/sdd: 931,51 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: TOSHIBA HDWD110 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xeffcdc8f

Device     Boot Start        End    Sectors   Size Id Type
/dev/sdd1  *     2048 1953521663 1953519616 931,5G  7 HPFS/NTFS/exFAT


Disk /dev/loop0: 4 KiB, 4096 bytes, 8 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop1: 105,82 MiB, 110960640 bytes, 216720 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop2: 104,19 MiB, 109252608 bytes, 213384 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop3: 55,66 MiB, 58363904 bytes, 113992 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop4: 55,66 MiB, 58363904 bytes, 113992 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop5: 63,46 MiB, 66547712 bytes, 129976 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop6: 63,95 MiB, 67051520 bytes, 130960 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop7: 81,26 MiB, 85209088 bytes, 166424 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop8: 91,69 MiB, 96141312 bytes, 187776 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop9: 260,71 MiB, 273375232 bytes, 533936 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop10: 289,78 MiB, 303853568 bytes, 593464 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

$ sudo df -h
Filesystem      Size  Used Avail Use% Mounted on
dev              16G     0   16G   0% /dev
run              16G  1,7M   16G   1% /run
/dev/sda1       345G  313G   16G  96% /
tmpfs            16G  273M   16G   2% /dev/shm
tmpfs            16G  228M   16G   2% /tmp
tmpfs           1,0M     0  1,0M   0% /run/credentials/systemd-journald.service
/dev/sdc1        69G   65G  784M  99% /mnt/Arch
/dev/sdc2        69G   53G   13G  81% /mnt/NEON
/dev/loop0      128K  128K     0 100% /var/lib/snapd/snap/bare/5
/dev/loop1      106M  106M     0 100% /var/lib/snapd/snap/core/16202
/dev/loop2      105M  105M     0 100% /var/lib/snapd/snap/core/17200
/dev/loop4       56M   56M     0 100% /var/lib/snapd/snap/core18/2829
/dev/loop3       56M   56M     0 100% /var/lib/snapd/snap/core18/2796
/dev/loop5       64M   64M     0 100% /var/lib/snapd/snap/core20/2015
/dev/loop6       64M   64M     0 100% /var/lib/snapd/snap/core20/2318
/dev/loop7       82M   82M     0 100% /var/lib/snapd/snap/gtk-common-themes/1534
/dev/loop8       92M   92M     0 100% /var/lib/snapd/snap/gtk-common-themes/1535
/dev/loop9      261M  261M     0 100% /var/lib/snapd/snap/kde-frameworks-5-core18/32
/dev/sdb2       1,8T  1,8T  1,8G 100% /mnt/2TB
/dev/loop10     290M  290M     0 100% /var/lib/snapd/snap/kde-frameworks-5-core18/35
/dev/sda3       446G  444G  2,7G 100% /mnt/DADOS
/dev/sda2       150G  135G   16G  90% /mnt/WIN10
tmpfs           3,2G  156K  3,2G   1% /run/user/1003

$ sudo lsblk -f
NAME   FSTYPE   FSVER LABEL     UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0  squashfs 4.0                                                        0   100% /var/lib/snapd/snap/bare/5
loop1  squashfs 4.0                                                        0   100% /var/lib/snapd/snap/core/16202
loop2  squashfs 4.0                                                        0   100% /var/lib/snapd/snap/core/17200
loop3  squashfs 4.0                                                        0   100% /var/lib/snapd/snap/core18/2796
loop4  squashfs 4.0                                                        0   100% /var/lib/snapd/snap/core18/2829
loop5  squashfs 4.0                                                        0   100% /var/lib/snapd/snap/core20/2015
loop6  squashfs 4.0                                                        0   100% /var/lib/snapd/snap/core20/2318
loop7  squashfs 4.0                                                        0   100% /var/lib/snapd/snap/gtk-common-themes/1534
loop8  squashfs 4.0                                                        0   100% /var/lib/snapd/snap/gtk-common-themes/1535
loop9  squashfs 4.0                                                        0   100% /var/lib/snapd/snap/kde-frameworks-5-core18/32
loop10 squashfs 4.0                                                        0   100% /var/lib/snapd/snap/kde-frameworks-5-core18/35
sda                                                                                 
├─sda1 ext4     1.0   ARCH      4c1b8d88-ae03-4daa-9733-103cfeffdd81   15,7G    91% /
├─sda2 ntfs           WIN10     3A2802E62802A0CD                       15,9G    89% /mnt/WIN10
└─sda3 ext4     1.0   DADOS     3050cb70-af8c-410f-ba73-8b6d70131ed7    2,6G    99% /mnt/DADOS
sdb                                                                                 
└─sdb2 ext4     1.0   2TB       cb0035ef-a728-41d3-87db-fe0bae21d9c9    1,8G   100% /mnt/2TB
sdc                                                                                 
├─sdc1 ext4     1.0   Arch      4ca092fc-7430-4ae6-bf4b-68be105f8908  783,8M    94% /mnt/Arch
├─sdc2 ext4     1.0   NEON      3640c417-a653-4198-9ae5-b81d30d77fe7   12,6G    76% /mnt/NEON
└─sdc3 ntfs           DADOS_LNV 5656FF2514176652                                    
sdd                                                                                 
└─sdd1 exfat    1.0             9629-04F2                                           
sr0

Last edited by Strangiato (Yesterday 15:50:16)

seth · Yesterday 15:10:31

3907026944*512-488378368*4096 = 0
You're using the entire disk (-1MB, that doesn't count) for the partition and the filesystem uses the entire partition.
As we've figured before, the amount of 1.8GB free +30GB filesystem overhead (you have to address the data somehow) + 1831GB of used and counted by du data sum up to this.
You are not missing "75GB of free space", it's all completely accounted for by the filesystem.

Check ncdu and the find command, maybe you can find the stuff you think your missing (is there anything in the "lost+found" directory after the FS check?) but there are absolutely no inconsistencies.

Strangiato · Yesterday 15:39:53

lost+found directory contains 76G, many files and folders with generic names:

$ sudo du -h|grep found
....
76G     ./lost+found

Thank you very much for the help @seth.

seth · Yesterday 15:43:14

Does gnome-disks not somehow forward that information from the fsck??

Strangiato · Yesterday 15:49:17

No. Gnome Disks only said that the file system was successfully repaired.

cryptearth · Yesterday 17:27:30

hm - you either have messed up pretty bad - or you really use your storage up to the brim

*meanwhile my zfs pool - enough free space to clone OPs entire storage - three times over

zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
vault  21.8T  9.48T  12.3T        -         -     9%    43%  1.00x    ONLINE  -

Arch Linux

#1 2025-06-06 21:42:46

[solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#2 Yesterday 06:50:17

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#3 Yesterday 12:29:10

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#4 Yesterday 12:48:44

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#5 Yesterday 12:59:09

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#6 Yesterday 13:23:18

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#7 Yesterday 13:28:33

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#8 Yesterday 13:36:47

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#9 Yesterday 13:54:38

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#10 Yesterday 14:09:25

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#11 Yesterday 14:26:07

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#12 Yesterday 14:30:11

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#13 Yesterday 14:52:03

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#14 Yesterday 15:10:31

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#15 Yesterday 15:39:53

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#16 Yesterday 15:43:14

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#17 Yesterday 15:49:17

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

#18 Yesterday 17:27:30

Re: [solved] Wrong free space after repairing EXT4 fs with Gnome Disks

Board footer