du -k and bdf show different utilization on mount point???

[Craig A. Sharp]

I have a disk on a single mount point that is showing 98% full. A bdf confirms this fact with 35 of 36 GB used. If I do a du -k on the mount point it is showing that only 25 of 36 GB is used.
What would be causing this difference and which one is correct?

Thanks,

Craig

[Patrick Wallek]

Actually they both could be correct! :) (Don't you just love Unix?!)

The cause is probably because someone removed a file, or several files, that were still in use. The space from those files will not be freed (unlinked) until the process(es) that are using those files either finish what they are doing (either normally or abnormally via 'kill'). This is the number that 'bdf' is reporting.

'du' is just basically adding up the sizes of all visible files in the directory. Since the files has been removed you can't see the filename and file stats., so du can't see it.

[Sridhar Bhaskarla]

Craig,

bdf|df would be the command to see the utilization on the mount point.

The information given by 'du' cannot be used to determine the utilization as it includes sizes of the mount points inside that mount point also. I am surprized to see why du -sk is reporting lesser than your bdf command in your case.

-Sri

[Sean OB_1]

bdf may show files that have been removed, but are still being used by active processes.

So it may report a larger than actual usage until the processes that were using the files end.

[Con O'Kelly]

Hi Craig

As Patrick has explained this is the most likely cause of the difference between 'du' and 'bdf' output.

To identify which file(s) are causing this descrepancy, you can use 'lsof' command as follows:

# lsof / | sort -rnk 7,7

This will show open files in the filesystem (sorted by file size) and which processes have them open (1st column).

You'll have to kill the process to free up the file(s) and hence space in the filesystem.
Its liklely that with a 10G difference, you'll be looking at a couple of very large files causing your problem. They should be fairly obvious straight away from lsof output.

Cheers
Con

[Hein van den Heuvel]

Hmm, I find it a little unlikely that 10GB out of 36GB would be 'in flight'. I suspect a static inconsistency, not a dynamic one (processes actively accesing already deleted files.). I'd try fsck for the filesystem in question. For example fsck_vxfs. Maybe some orphaned files and directories (allocated but unreferenced) that can be entered in lost+found?

fwiw,
Hein.

[Robert True]

Don't you want 'df -k' to compare apples to apples with 'bdf' ? 'df -k' is the old SytemV (and others) unix cmd for disk space utilization. You might get some slight variation (say 1%) due to rounding errors, but not 10gb.

Rt.

[Fred Ruffet]

Have a look at this thread :
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=629399

I believe it matches your problem.

Regards,

Fred

[Anonymous]

In case we delete a file without checking with fuser for a process first bdf will display the file's space as consumed until the process is terminated.

To detect deleted files held open by a process HP used a tool for me called "uli . A tool to list unlinked (removed) files that are still in use."

And I've been told that lsof might be used as well like

# lsof +aL1 /usr

However, did not have to try that ever since...

BTW we had an oracle process consuming several 100MB in a deleted file "/" - killed the process HP found with "uli" and we were fine again - without reboot that would have had the same result ;-)