I have a 45-ish-gig virtual drive connected to a VM as my root partition.
root@alang-web:~# df -h
Filesystem Size Used Avail Use% Mounted on
udev 2.0G 0 2.0G 0% /dev
tmpfs 396M 5.6M 390M 2% /run
/dev/sda1 46G 41G 2.3G 95% /
tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
/dev/sdb1 148G 15G 126G 11% /mnt/data
cgmfs 100K 0 100K 0% /run/cgmanager/fs
alang-web-backup 621G 256G 366G 42% /media/sf_alang-web-backup
tmpfs 396M 0 396M 0% /run/user/1000
As you can see, it reports 41 gigs of 46 gigs used.
And then there's this:
root@alang-web:~# du -shx /
27G /
And this:
root@alang-web:~# tune2fs -l /dev/sda1
tune2fs 1.42.13 (17-May-2015)
...
Block count: 12058624
Reserved block count: 602931
Free blocks: 1209455
...
And going to init 1 and running a fsck -f / reports no errors of any kind.
Where the heck is that 41G - 27G = 14G of space that is supposedly being used but is not visible to du? It can't be doubly-hard-linked files, that would cause du to be HIGHER than df (and anyway I don't know what would be doing that). It can't be unlinked files that are still in use, I have rebooted multiple times and the numbers simply don't change much. Also there's this:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NLINK NODE NAME
php-fpm7. 992 root 3u REG 8,1 0 0 1837559 /tmp/.ZendSem.dSWbfL (deleted)
mysqld 1020 mysql 4u REG 8,1 0 0 1837551 /tmp/ibybXrs3 (deleted)
mysqld 1020 mysql 5u REG 8,1 0 0 1837623 /tmp/ibVK2BUX (deleted)
mysqld 1020 mysql 6u REG 8,1 0 0 1837628 /tmp/ibavDMmS (deleted)
mysqld 1020 mysql 7u REG 8,1 0 0 1837629 /tmp/ib5MSHjH (deleted)
mysqld 1020 mysql 11u REG 8,1 0 0 1837631 /tmp/ibf8ZvTB (deleted)
php-fpm7. 1067 www-data 3u REG 8,1 0 0 1837559 /tmp/.ZendSem.dSWbfL (deleted)
php-fpm7. 1068 www-data 3u REG 8,1 0 0 1837559 /tmp/.ZendSem.dSWbfL (deleted)
apache2 1088 root 40u REG 8,1 0 0 1837632 /tmp/.ZendSem.3m0mZe (deleted)
apache2 1091 www-data 40u REG 8,1 0 0 1837632 /tmp/.ZendSem.3m0mZe (deleted)
apache2 1092 www-data 40u REG 8,1 0 0 1837632 /tmp/.ZendSem.3m0mZe (deleted)
apache2 1093 www-data 40u REG 8,1 0 0 1837632 /tmp/.ZendSem.3m0mZe (deleted)
apache2 1094 www-data 40u REG 8,1 0 0 1837632 /tmp/.ZendSem.3m0mZe (deleted)
apache2 1095 www-data 40u REG 8,1 0 0 1837632 /tmp/.ZendSem.3m0mZe (deleted)
apache2 1275 www-data 40u REG 8,1 0 0 1837632 /tmp/.ZendSem.3m0mZe (deleted)
apache2 1277 www-data 40u REG 8,1 0 0 1837632 /tmp/.ZendSem.3m0mZe (deleted)
apache2 1278 www-data 40u REG 8,1 0 0 1837632 /tmp/.ZendSem.3m0mZe (deleted)
Those are all the unlinked files that it lists for that file system currently. I don't know how big those are (perhaps the size is inaccurate for files that are unlinked, or perhaps those really are size-0 files that are being used for semaphores or something of the sort.) However, it seems kind of unlikely that they're 14 gigs.
Is there some subtlety of ext4 that I don't know about? I freely admit to being more familiar with ext3 and HFS+. Is this somehow sharing space with some other partition or something like that, and the command line tool df hasn't kept up with modern times? Is the drive just broken in a way fsck can't even detect, let alone fix?
Just to preempt one other suggestion:
root@alang-web:~# cat > /tmp/blar
adsf
root@alang-web:~# du -sh /tmp/*
4.0K /tmp/blar
root@alang-web:~#
So no, du does not report actual file sizes, it reports the size on disk including padding out to the next largest block size.
