Gparted shows Linux filled less than it actually is. How to fix it?

Question

I've had Ubuntu System with the size of 100 GiB. I've made some manipulations for repairing the system and, as a result, my Linux cannot boot, and GParted shows there are only 1 GiB filled on the system. But I know that all 100 Gib are filled. I've tried mkfs and fsck, but it didn't help. Also after mounting Linux command ls /mnt shows only one folder, lost+found, which is empty. I don't have backups (only superblock backups) (I know I'm jerk).

Is there a way to return all 100 GiB of data in Linux?

Sequence of commands in terminal:

ubuntu@ubuntu:~$ sudo mkfs -t ext4 -n /dev/nvme0n1p4
mke2fs 1.45.5 (07-Jan-2020)
/dev/nvme0n1p4 contains a ext4 file system
    created on Thu Feb 29 10:25:01 2024
Proceed anyway? (y,N) y
Creating filesystem with 26214400 4k blocks and 6553600 inodes
Filesystem UUID: f6d50715-fde7-49a1-971b-bcd8fa9aca87
Superblock backups stored on blocks: 
    32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
    4096000, 7962624, 11239424, 20480000, 23887872
ubuntu@ubuntu:~$ sudo fsck -b 23887872 /dev/nvme0n1p4
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
/dev/nvme0n1p4 was not cleanly unmounted, check forced.
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
Block bitmap differences:  +(32768--33792) +(98304--99328) +(163840--164864) +(229376--230400) +(294912--295936) +(819200--820224) +(884736--885760) +(1605632--1606656) +(2654208--2655232) +(4096000--4097024) +(7962624--7963648) +(11239424--11240448) +(20480000--20481024) +(23887872--23888896)
Fix<y>? yes
Padding at end of inode bitmap is not set. Fix<y>? yes
/dev/nvme0n1p4: ***** FILE SYSTEM WAS MODIFIED *****
/dev/nvme0n1p4: 11/6553600 files (0.0% non-contiguous), 557653/26214400 blocks
sudo fsck -b 20480000 /dev/nvme0n1p4
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
/dev/nvme0n1p4 was not cleanly unmounted, check forced.
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
Padding at end of inode bitmap is not set. Fix<y>? yes
Block bitmap differences: Group 1 block bitmap does not match checksum.
FIXED.
/dev/nvme0n1p4: ***** FILE SYSTEM WAS MODIFIED *****
/dev/nvme0n1p4: 11/6553600 files (0.0% non-contiguous), 557653/26214400 blocks

From what you have pasted, it looks like you formatted the partition? If you've done that, you can almost certainly kiss the data goodbye. — popey, Feb 29 '24 at 12:06
Popey , yes, firstly, I accidentally formatted the partition to unknown using testdisk. After that I've used GParted and have formatted it to btrfs and then to ext4 like it is now. But why does reformatting destroy the data and why does GParted show me that there are about 1 GiB of memory filled? — davynci, Feb 29 '24 at 12:48
Gparted saves 5% of space for the super user. https://unix.stackexchange.com/a/119904/1610 — popey, Feb 29 '24 at 13:02
Does this answer your question? Why is there 4.86(maybe 15.1) GB of USED-space on a newly partitioned and formatted 298 GB drive (as ext4 by Gparted) — popey, Feb 29 '24 at 13:03
Yes, it answers my question. This will be a good lesson for me to make backups. Thanks! — davynci, Feb 29 '24 at 13:07
Does this answer your question? How to recover deleted files? — Daniel T, Feb 29 '24 at 17:57

Gparted shows Linux filled less than it actually is. How to fix it?

0 Answers0