Skip to main content

I will illustrate here different cases that causes du being different from df.

df counts the file system allocated blocks, du use the size information of each filesfile. A difference can have many causecauses:

  1. Unlinked (deleted) files that are still open by application. The file information are missing, the block are still allocated. lsof +aL1 <filesystem> will helps you to identfyidentify the processes. Most of the time you have to kill the processes to free the space (it depends on the process, sometimes a configuration reload is sufficient).

  2. Files beneath mount points hidden to du but not to df. debugfs can helpshelp you to read the filesystem.

    $ sudo debugfs debugfs 1.42.12 (29-Aug-2014) debugfs: open /dev/xxx (the desired file system device) debugfs: cd /boot debugfs: ls -l 1966081 40755 (2) 0 0 4096 26-May-2016 16:28 . 2 40555 (2) 0 0 4096 11-May-2016 10:43 .. 1974291 100644 (1) 0 0 0 26-May-2016 16:28 bob <---<<< /boot/bob is hidden by /boot fs

    $ sudo debugfs 
    debugfs 1.42.12 (29-Aug-2014)
    debugfs:  open /dev/xxx    (the desired file system  device)
    debugfs:  cd /boot
    debugfs:  ls -l 
     1966081   40755 (2)      0      0    4096 26-May-2016 16:28 .
           2   40555 (2)      0      0    4096 11-May-2016 10:43 ..
     1974291  100644 (1)      0      0       0 26-May-2016 16:28 bob   <---<<< /boot/bob is hidden by /boot fs
    
  3. Sparse files that looks bigger than the reality. nonNon allocated blocks are not counted by df but the apparent file size is counted by du.

Note that Hard links do not foolsfool du.

I will illustrate here different cases that causes du being different from df.

df counts the file system allocated blocks, du use the size information of each files. A difference can have many cause:

  1. Unlinked (deleted) files that are still open by application. The file information are missing, the block are still allocated. lsof +aL1 <filesystem> will helps you to identfy the processes. Most of the time you have to kill the processes to free the space (it depends on the process, sometimes a configuration reload is sufficient).

  2. Files beneath mount points hidden to du but not to df. debugfs can helps you to read the filesystem.

    $ sudo debugfs debugfs 1.42.12 (29-Aug-2014) debugfs: open /dev/xxx (the desired file system device) debugfs: cd /boot debugfs: ls -l 1966081 40755 (2) 0 0 4096 26-May-2016 16:28 . 2 40555 (2) 0 0 4096 11-May-2016 10:43 .. 1974291 100644 (1) 0 0 0 26-May-2016 16:28 bob <---<<< /boot/bob is hidden by /boot fs

  3. Sparse files that looks bigger than the reality. non allocated blocks are not counted by df but the apparent file size is counted by du.

Note that Hard links do not fools du

I will illustrate here different cases that causes du being different from df.

df counts the file system allocated blocks, du use the size information of each file. A difference can have many causes:

  1. Unlinked (deleted) files that are still open by application. The file information are missing, the block are still allocated. lsof +aL1 <filesystem> will helps you to identify the processes. Most of the time you have to kill the processes to free the space (it depends on the process, sometimes a configuration reload is sufficient).

  2. Files beneath mount points hidden to du but not to df. debugfs can help you to read the file system.

    $ sudo debugfs 
    debugfs 1.42.12 (29-Aug-2014)
    debugfs:  open /dev/xxx    (the desired file system  device)
    debugfs:  cd /boot
    debugfs:  ls -l 
     1966081   40755 (2)      0      0    4096 26-May-2016 16:28 .
           2   40555 (2)      0      0    4096 11-May-2016 10:43 ..
     1974291  100644 (1)      0      0       0 26-May-2016 16:28 bob   <---<<< /boot/bob is hidden by /boot fs
    
  3. Sparse files that looks bigger than the reality. Non allocated blocks are not counted by df but the apparent file size is counted by du.

Note that Hard links do not fool du.

Source Link
Emmanuel
  • 4.3k
  • 2
  • 26
  • 31

I will illustrate here different cases that causes du being different from df.

df counts the file system allocated blocks, du use the size information of each files. A difference can have many cause:

  1. Unlinked (deleted) files that are still open by application. The file information are missing, the block are still allocated. lsof +aL1 <filesystem> will helps you to identfy the processes. Most of the time you have to kill the processes to free the space (it depends on the process, sometimes a configuration reload is sufficient).

  2. Files beneath mount points hidden to du but not to df. debugfs can helps you to read the filesystem.

    $ sudo debugfs debugfs 1.42.12 (29-Aug-2014) debugfs: open /dev/xxx (the desired file system device) debugfs: cd /boot debugfs: ls -l 1966081 40755 (2) 0 0 4096 26-May-2016 16:28 . 2 40555 (2) 0 0 4096 11-May-2016 10:43 .. 1974291 100644 (1) 0 0 0 26-May-2016 16:28 bob <---<<< /boot/bob is hidden by /boot fs

  3. Sparse files that looks bigger than the reality. non allocated blocks are not counted by df but the apparent file size is counted by du.

Note that Hard links do not fools du