Home / ubuntu / Questions / 1284330
Accepted
Kokizzu
Asked: 2020-10-17 08:57:09 +0800 CST

Weird disk usage statistics

  • 772

When I use df -h it shows:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdg5       218G  151G   56G  74% /

Which correct capacity according to lsblk

sdg      8:96   1 223,6G  0 disk 
├─sdg1   8:97   1   1,9G  0 part /boot/efi
├─sdg2   8:98   1     1K  0 part 
└─sdg5   8:101  1 221,7G  0 part /

But when I use du -h --max-depth 2 | grep G it shows similar result as sudo baobab

36G     /home/kyz
11G     /home/kcy
47G     /home
11G     /usr
13G     /var/lib
22G     /var
8,2G    /snap

which the totals should be only using around 100 GB (detected only 87 GB in baobab probably because of /snap directory should not counted), where is my other 51 GB disk usage gone into?

sudo baobab result

EDIT1 Tried one solution on the answer, seems the same:

sudo mount -o bind / /mnt
du -hs /mnt
# 80 GB

EDIT2 Tried another solution from the answer, only few megabytes locked (total less than 2 GB) for deletion:

sudo lsof | grep deleted
chrome     463364  485536 MemoryInf           kcy  txt       REG              8,101   167169112   11273579 /opt/google/chrome/chrome (deleted)
chrome     463364  485536 MemoryInf           kcy    5r      REG              8,101    10518160   11273640 /opt/google/chrome/icudtl.dat (deleted)
MainThrea  729751                                kyz   14r      REG              8,101    25411839    7085195 /usr/lib/firefox/omni.ja (deleted)
MainThrea  729751                                kyz   15r      REG              8,101    43682061    7085151 /usr/lib/firefox/browser/omni.ja (deleted)
disk-usage 20.04

2 Answers

  1. Best Answer

    It appears that this issue tends to create numerous duplicates over the stackexchange network. Here is the direct link to the approved solution:

    https://serverfault.com/questions/275206/disk-full-du-tells-different-how-to-further-investigate

    but you should be able to find more by googling "du vs df mounted disks".

    Have a nice day

    • 1

  2. Found the culprit, it was yakuake for my case, the scroll log was way too large (11GB -- journalctl -f and 34GB -- ktorrent), reseting the scrollback (or setting it low 32k for example, solves this issue)

    found by typing this command: lsof -Pn +L1 (this is way faster than any other lsof command I found on another stackexchange sites).

    The full command for checking:

    lsof -Pn +L1 2> /dev/null | 
awk '{if ($NF=="(deleted)") {x=4;y=1} else {x=2;y=0}; {print $(NF-x) "  " $(NF-y) } }' | 
sort -nru | 
numfmt --field=1 --to=iec
    • 1