df and du both incorrectly report that my root partition, a 100GB SSD, has no remaining space and uses 100G respectively; 85G in /home/steven alone. A simple summing of the disk usage provided by du, however, reports less than 13G used.

How can I fix this?


~ » du -sh ~
85G   /home/steven

~ » du -b ~ | wc -l

~ » du -h ~ | sort -h | tail -n 1
85G   /home/steven # 91088489808 bytes if using -b for du

~ » du -b ~ | sort -n | head -n 15040 | cut -f 1 | perl -ne 'BEGIN{$i=0;}$i+=$_;END{print $i.qq|\n|;}'
12735983847 # 11-12G, roughly

There's a huge discrepancy between 85G and 11G or 12G, obviously. I ran lsof +L1 and eliminated all of the processes with files marked deleted, but still no luck.

I have several soft links in $HOME pointing to directories (e.g., repos) on an external hard drive, which may be an issue based on some Stack Exchange posts I read, but I can't seem to understand it.

What should I do next?

  • What about a tune2fs -m 0 /dev/...?
    – peterh
    Feb 4, 2015 at 21:04
  • No change in du after running that, unfortunately, but it did free up 5G per df. Feb 4, 2015 at 21:10
  • 1
    Why would you filter out deleted files? They're still going to be on disk until the file handle is closed.
    – Bratchley
    Feb 4, 2015 at 21:19
  • I'd also turn your reserved space back on unless this is on the /home filesystem. If it's on root you actually need that space, just probably not as much space as it reserved automatically.
    – Bratchley
    Feb 4, 2015 at 21:23
  • @Bratchley, I ran kill -9 on all of the PIDs. Won't that release the file handles? Also, how much space would you recommend allocating? Feb 4, 2015 at 21:37

2 Answers 2


du does a depth-first traversal of the given tree. By default, it shows the usage of every directory tree, showing the inclusive disk usage of each:

$ du ~
4      /home/bob/Videos
40     /home/bob/.cache/abrt
43284  /home/bob/.cache/mozilla/firefox
43288  /home/bob/.cache/mozilla
12     /home/bob/.cache/imsettings
48340  /home/bob/.cache
4      /home/bob/Documents
48348  /home/bob

If given the -a option, it will additionally show the size of every file.

With the -s option, it will show just the total size of each argument file or directory tree.

$ du -s ~
48348  /home/bob
$ du -s ~/*
4      /home/bob/Videos
4      /home/bob/Documents

So, when you ran

$ du -b ~ | wc -l

$ du -b ~ | sort -n | head -n 15040 | cut -f 1 | \
    perl -ne 'BEGIN{$i=0;$i+=$_;END{print $i.qq|\n|;}'

you were summing up the size of everything under your home directory - multiple times, unfortunately, because the size reported on each line is inclusive of all subdirectories - but because you omitted the final line of du's output, which would be the line for /home/steven, du didn't count the size of any of the regular files in the top level of your home directory. So the sum didn't include your very large .xsession-errors file.

And when you ran

du -sb ~ returns 91296460205, but the sum of du -sb ~/* is only 1690166532

your du -sb ~/* output didn't include any files or directories in your home directory that begin with ..

Both du ~ | tail -1 and du -s ~ should do a reasonable job of showing your home directory's disk usage (not including deleted-but-open files, of course), but if you want to sum up all the file sizes without relying on du, you can do something like this (assuming a modern find that supports the printf %s format to show the size in bytes):

find ~ -type f -printf '%s\n' | perl -ne 'BEGIN{$i=0;$i+=$_;END{print $i.qq|\n|;}'
  • Thank you for the detailed reply, Mark. And the -printf trick, which is much quicker than the -exec du -h '{}' \; that I used. Feb 5, 2015 at 20:13

You're summing the bytes, but the filesystem's block size is probably much larger than 1 byte. For an accurate count, you should be rounding each file's size up so that it's a multiple of the filesystem blocksize.

With GNU coreutils installed, you can run stat --file-system $HOME to find the block size of the filesystem.

On average, files will waste half a block. Multiply half a block by the number of files in $HOME and see if the result is close to 70GiB. If so, then your mystery is solved.

  • Thanks for the block size tip. $HOME's block size is 4096 bytes. Including directories (find ~ | wc -l), $HOME has 81846 files--more than what du found. Feb 5, 2015 at 1:27
  • .xsession-errors was 83GB, per du -h .xsession-errors. Oddly, that file was excluded from du -h ~/ | sort -h. Feb 5, 2015 at 1:42
  • After deleting that file, du -sh / shows 20G now, but df shows 97% usage. Feb 5, 2015 at 1:46
  • lsof +L1 shows that the .xsession-errors file descriptor is still open, held by gdm. Would it be a disaster if I truncate the file in /proc/pid/fd/? Feb 5, 2015 at 1:49
  • sudo truncate -s 0 /proc/[pid]/fd/[fd] worked. Feb 5, 2015 at 10:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .