Contents
How does DF arrive at its total value?
This is how du arrives at its total value. df looks at the file system disk block allocation maps to arrive at its total and free values. The file system allocates some of the disk blocks in the file system to record its data. This data is referred to as meta data. Meta data is not visible to most user-level programs.
Why are numbers from ” Du-s ” and ” DF ” disagree?
# fuser -dV /mntpt will give you information about files that have been deleted, but for whatever reason AIX still has a process holding onto the inode number. This space will be reclaimed after the process has closed the inode. This can be done by stopping the process or killing it.
Why does DF not show reduced file size?
However, df does not show a reduced size because all blocks in the file system remain allocated until the application that has the file open closes the file. After the file closure, df shows reduced usage for the file system.
How to get the output from Du to match that from DF?
To get the output from du to match that from df, we must add in the meta data. First, convert 41 4K blocks to 512-byte units: So there are 344 512-byte blocks allocated on this empty file system. For example: This value does match the output from the free column reported by df /foo. This calculation was easy to perform on an empty file system.
Why does DF show up differently than du?
This space will be reclaimed after the process has closed the inode. This can be done by stopping the process or killing it. So with the process killed off, the space should be allocated back and df should show up differently. The following compares ls output with that of du and df for sparse files.
Why is my DF not running the correct way?
It may be that you are not running the correct df; perhaps there is a badly-named alias or shellscript in your path. Run which df to check. If you are running the correct df, then perhaps it has been corrupted or overwritten.