File system free space not showing in bdf

[Joe Pritchard]

I recently moved a 238mb file with the mv command. After doing this, the %used display still inidicates the same amount as does the avail column. Did I miss something here? The file really did move.
Thanks for your help.
Joe Pritchard

[Anthony Goonetilleke]

Install patch PHKL_18543 and its dependencies to resolve the bdf problem

[James R. Ferguson]

Joe:

If you moved the file within the same filesystem, then, there will be no change in the percentage used. In this case a 'mv' is simply a rename operation.

If you moved the file from one filesystem to another, then the 'bdf' percentage used will only change if the change in space is significant to 1% or more.

...JRF...

[Jennifer Chiarelli]

PHKL_18543 is for HP-UX 11.0. Is that what you are running? There are different patches related to bdf for HP-UX 10.20.

[James R. Ferguson · Accepted solution]

Joe:

I may have taken your query too literally. If I did, and I told you the obvious, then here (perhaps) is some better information.

See document #A5826096 or #PU940407163611.

Sometimes after removing a file, a "bdf" command will not show that the file system space was restored. This may occur when a user removes a file that another process still has open.

The data blocks for that file will not be restored to the file system until the process either closes the file descriptor for that file or the process terminates. For example, with a database file that has not returned its space, close the database down or try killing the database handler daemon.

Note that if the process that holds the open file descriptor becomes defunct, it will hold those data blocks until the system is rebooted.

Does this shed better light?

...JRF...

[Joe Pritchard]

I appreceate the replies. Here are the additional details. I have UX 10.20.
I did move it to a different file system. It definately is more that 1%.

The file was listener.log for Oracle 8.0.5. I stopped the listener's logging with the LSNRCTL utility before moving the file, however I did not check to see if any other processes had it open. Upon starting the listener log again, it created a new file and logging is working normally. From your last reply, should I try stopping the Listener and restarting it?
Thanks
Joe Pritchard

[Alan Riggs]

It seems likely that another process was attached to the listener log, though I do not know which process that would be. Doing an fuser on the logical volume and paring down from there might allow you to identify it. Since the listener has already been restarted since the move, I doubt recycling it would resolve the issue, but who know. Shutting it down again might close whatever other process has a pointer into the original file space.

[Joe Pritchard]

Stopping and starting the Listener did the trick. I now have the 235mb free. Isn't there another way to zero a log file using Cat to Null or something like that? A guy showed me a while back but I can't remember.

[James R. Ferguson]

Joe:

Do this:

cat /dev/null > /tmp/log #...or whatever...

...JRF...

[Alan Riggs]

Or, if you don't like typing:

> /dir/log.file

[Ossie de Jongh]

This one can be a bit of a headache. I had a disk that got 100% full and moved a big file to another disk. Unfortunately my database wouldnt run cause it was still reporting out of disk space on dev/whatever, so this is what I did:
fuser -cu /*disk* which will display the list of connections and then I killed them all, not nice, almost a hundred, but at least the space became free.