3

I am aware of the expected reasons that du and df will report differences, however I cannot imagine these would justify the discrepancy I am seeing:

[root@example.com mynfsmount]# df -h /opt/mynfsmount
Filesystem            Size  Used Avail Use% Mounted on
192.168.0.92:/data/export/examplecom
                      3.0T  2.7T  391G  88% /opt/mynfsmount
[root@example.com mynfsmount]# du -sh /opt/mynfsmount
13G     /opt/mynfsmount

i.e. df is reporting ~300 times the usage du reports.

It may be significant that the NFS server is a Synology box, the host is Centos 5.11 (erk!) and there is no lost+found directory in /opt/mynfsmount. This is a system I have inherited and there is little information available about how much data is expected to be there.

Currently lsof only reports a single deleted file still open.

Any suggestions of what I try next?

symcbean
  • 5,540

1 Answers1

1

I think this is expected behaviour.

Lets say you have a server with a filesystem mounted as /foo and that filesytem contains two directories bar and baz giving you /foo/bar/ and /foo/baz/. Lets say:

  • /foo is a 100GB file system
  • /foo/bar/ contains 10GB of files
  • /foo/baz/ contains 20GB of files
  • leaving 70GB free.

If you then export /foo/bar through NFS. And mount it on a client as /mnt/bar. Then on the clint you execute both:

df -h /mnt/bar
du -hs /mnt/bar

I would expect:

  • df to show 30GB used, 70GB free, 100GB totoal.
  • du to show only 10GB used.

The other 20GB has not been exposed through NFS, but it will show up on your usage when interrogated in df. This is normal behavior for remote file system protocols on most operating systems.

In short, df shows the statistics for the whole file system as mounted on the remote server. du shows the total size of files you have access to.

Note: There are many other reasons du may not have access to some files contained on a file system. A couple of other reasons include:

  • It is possible to delete (unlink) a file while a program is still writing to it. If this happens the file remains on disk until all references (including open file handles) are removed. du cannot find these because they have no filename. But they will still have an inode and so still show up when checked with df.
  • Likewise filesystems can occasionally become corrupted. Files can still exist after all references have been closed due to corruption. This is one good reason to perform semi-regular fsck checks on your disk.

By far the most likely in your scenario is the export example I showed at the top. But if you are concerned then do unmount and fsck your disk.

Philip Couling
  • 18,733