Edit: SOLVED thanks to r00ty !

Hello, I have this weird issue that my Debian 11 will tell me the root folder is full, while I can only find files for half of the accounted space.

df -h reports 56G while the disk analyser (sudo baobab) only finds 28G.

Anyone ever encountered this? I don’t have anything mounted twice… (Not sure what udev is). Also it does not add up to 100%, it should say 7.2G left not 4.1G

df -h /dev/sda* Filesystem Size Used Avail Use% Mounted on udev 16G 0 16G 0% /dev /dev/sda1 511M 22M 490M 5% /boot/efi /dev/sda2 63G 56G 4.1G 94% / /dev/sda4 852G 386G 423G 48% /home

Edit: my mtab

Edit 2: what Gparted shows

  • palordrolap@kbin.run
    0·
    3 months ago

    You might have some files hard-linked across directories, or worse (but less likely), there’s a directory hard-link (not supposed to happen) somewhere.

    For the uninitiated, a hard-link is when more than one filename points at the same file data on the disk. This is not the same as a symbolic link. Symbolic links are special files that contain a file or directory name and the OS knows to follow them to that destination. (And they can be used to link to directories safely.)

    Some programs are not hard-link aware and will count a hard-linked file as many times as it sees it through its different names. Likewise they will count the entire contents of a hard-linked directory through each name.

    Programs tend not to be fooled by symlinks because it’s more obvious what’s going on.

    Try running a duplicate file finder. Don’t use it to delete anything, but it might help you determine which directories the files are in and maybe why it’s like that.

    Also back up everything important and arrange for a fsck on next boot. If it’s a hard-linked directory fsck might be able to fix it safely, but it might choose the wrong name to be the main one and remove the other, breaking something. Or remove both. Or it’s something else entirely, which by “fixing” will stabilise the system but might cause some other form data loss.

    That’s all unlikely, but it’s nice to have that backup just in case.

  • umami_wasabi@lemmy.ml
    0·
    3 months ago

    What FS you’re on? I’m using BTRFS and have the same problem. Simply because disk analyzer doesn’t read snapshots.

    • BeatTakeshi@lemmy.worldOP
      0·
      3 months ago

      Nope (well better than df for the percentage, same as Gparted and lsblk) - thanks for this utility though

      duf /

  • gnuhaut@lemmy.ml
    0·
    3 months ago

    Very weird, I can think of some things I might check:

    • It is possible that you have files on disk that don’t have a filename anymore. This can happen when a file gets deleted while it is still opened by some process. Only the filename is gone then, but the file still exist until that process gets killed. If this were the problem, it would go away if you rebooted, since that kills all processes.

    • Maybe it is file system corruption. Try running fsck.

    • Maybe the files are impossible to see for baobab. Like if you had gigs of stuff under (say) /home on you root fs, then mount another partition as /home over that, those files would be hidden behind the mount point. Try booting into a live usb and checking your disk usage from there, when nothing is mounted except root.

    • If you have lots and lots of tiny files, that can in theory use up a lot more disk space than the combined size of the files would, because on a lot file systems, small files always use up some minimum amount of space, and each file also has some metadata. This would show up as some discrepancy between du and df output. For me, df --inodes / shows ~300000 used, or about 10% of total. Each file, directory, symlink etc. should require one inode, I think.

    • I have never heard of baobab, maybe that program is buggy or has some caveats. Does du -shx / give the same results?