bdf outputs discrepancy disk usage

[George Liu_2]

the output of bdf showed the following:
/dev/vg02/lvol1 4007201 3606487 0 100% /data

the disk was not reclaimed after i deleted a big file and sync. Any idea?

[Michael Tully]

Hi George,

You will most likely find that the process
that belonged to the large file that you
removed is still running. You need to
identify this process and kill it. You
could try 'fuser /dev/vg02/lvol1' and try
to trace the offender. If you have 'lsof'
this will also help by using 'lsof -i'

HTH
-Michael

[A. Clay Stephenson]

HI George:

You have to understand how rm and the underlying system call unlink() works. rm (unlink) remove the file's directory entry and reduces the link count by one. If the link count is zero (no other links to this file (inode)) AND no process has the file open then and only then are the filesystem blocks deallocated. In fact, one of the standard idioms in using temp files is to create a file
(e.g. /var/tmp/xx3456.tmp), open the file, unlink (rm) the file, but don't close it. The process can then read from and write to this file to it's heart's content but there is no directory entry for it. Only when the file is closed (or the process exits) is the space reclaimed.

You need to user fuser or lsof to find the process that has this file open and kill it. The space will then reappear.

Clay

[George Liu_2]

Thank you all,

I used
cat /dev/null > filename
rm filename
to delete the file. Don't know why still have the problem.

George

[A. Clay Stephenson]

Hi George:

If you created the file with /dev/null then your file should have been 0 bytes longs.
That is not your problem. You need to run fuser /data or much better lsof /data if you have lsof installed on your system. That will show you the process that is really using the space. You can download lsof from one of the HP-UX Porting Centers; it is really one of those utilities no UNIX box should be without.

Clay