1

I have a centos system that is reporting more disk usage using df than it is using du. I've read that this can happen when a file handle has not been closed. However, I've restarted the system multiple times and lsof does not reveal any stranded file handles.

This host is mirroring another host I manage using lftp nightly. I have set up apache on this host, pointing it to the mirrored directory using a symbolic link. The actual mirrored data is about 12-13 GB. Based on this the 14 GB number seems to be correct and df is reporting an extra 9 GBs.

What could be causing this?

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda        48G   23G   23G  50% /
tmpfs           492M  112K  492M   1% /dev/shm
$ du -hs / 2>/dev/null
14G     /
msw
  • 42,753
  • 9
  • 87
  • 112
Kylos
  • 1,888
  • 14
  • 24
  • found a solution on https://serverfault.com/a/315945/547765, restart syslogd works for me. – YNX Aug 08 '21 at 15:48

2 Answers2

1

Run an fsck on that drive.

df will give you the number of blocks in the disk's count of unallocated blocks, du reports how many blocks are accessible through the filesystem. You can see the differences in these methods because df is instantaneous (looking up a number) and du takes an amount of time proportional to the number of files (i-nodes to be precise) it has to inspect.

There can be 9GB of space absent from the free count while not having a filename by which to reach them. This is a common form of filesystem corruption.

msw
  • 42,753
  • 9
  • 87
  • 112
  • I ran fsck and didn't get any prompts to repair. It gave this status: /dev/xvda: 150374/5549696 files (38.9% non-contiguous), 6014203/12517376 blocks – Kylos Jul 03 '15 at 19:13
  • And 6014203/12517376 is about 50%. so df is probably correct. I'd never use du to count the space that isn't being used; that's not its job. – msw Jul 03 '15 at 19:18
  • Yeah, I noticed that. Based on the amount of data I've mirrored, I should have around 14GB. I was using du to try to locate the files that were responsible for the 9 GB. Interestingly, when I use a rescue partition and mount my volume, du shows 23 GB, but when I mount it normally, it shows 14 GB. – Kylos Jul 03 '15 at 19:38
  • Above is probably because I was not running du as root in a normal session. Using du I see that /var/spool/postfix/maildrop appears to be the culprit, taking up the missing 9 GB. – Kylos Jul 03 '15 at 19:42
0

Run du as root. Files that are not accessible by your user account will not be included in the total sum, so you must run as root to see the sum of all files on the disk.

Kylos
  • 1,888
  • 14
  • 24
  • 1
    Or at least not throw away the permission denied error messages: `2>/dev/null` – msw Jul 03 '15 at 20:03
  • 1
    It should have been my first clue when I added that to the command. It practically hit me in the face, but I still missed it. Thanks for your help anyway. – Kylos Jul 03 '15 at 23:02