7

What explains the discrepancy in usage (82 GB vs 13 GB) that I see below?

  • Using df:

    $ df -h /
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              96G   82G  9.9G  90% /

  • Using du:

    $ sudo du -cshx /
13G     /
13G     total
Amelio Vazquez-Reina
  • 40,169
  • 77
  • 197
  • 294
  • 2
    Maybe you have 69 gigs of data in a subdirectory that got mounted over where `du` can't see it? – Shadur Apr 11 '17 at 13:48
  • 2
    Might be because of files that were deleted but are still kept open by some process; you should try `lsof +L1`. – user2233709 Apr 11 '17 at 13:48
  • 2
    Relevant: http://unix.stackexchange.com/questions/120311/why-are-there-so-many-different-ways-to-measure-disk-usage – terdon Apr 11 '17 at 13:54
  • 1
    If the filesystem is [btrfs](https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21_Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21) things can get messy. – StrongBad Apr 11 '17 at 13:56

1 Answers1

6

-x option is a false friend as its purpose is to skip things. That option never gives you the complete picture.

To get a complete listing, use bind mounts and then du, ncdu, xdiskusage, baobab or whatever you wish on the bound directory without skip options:

mkdir /mnt/root
mount --bind / /mnt/root
ncdu /mnt/root

Then you might discover you have lots of stuff in /mnt/backup (because it wasn't mounted when the backup task ran), or a giant file in /dev (result of a dd if=/dev/zero of=/dev/sdx when no /dev/sdx existed and no tmpfs was mounted in /dev).

It could also be a deleted file still used by a process, but people don't usually ask about it as it's gone after reboot. It could also be a filesystem inconsistency, but that too would be gone after reboot (if it forces fsck in the process).

frostschutz
  • 47,228
  • 5
  • 112
  • 159
  • Thanks! Rebooting the machine did it +1. Interesting that `du` "loses" track of space until I restarted the machine – Amelio Vazquez-Reina Apr 11 '17 at 14:38
  • 1
    @AmelioVazquez-Reina The usual reason is that there's a large deleted file that some process still has open. The file contents don't go away until the process closes it, but `du` can't count it because it just traverses the directory. – Barmar May 22 '17 at 19:56