Filesystem reporting 100% when there is 16GB of space

[Sean Dale]

We have a filesystem called /oradata/tmp where the dbf files are stored (for temporary tablespaces for our development databases). The filesystem was 100% so I used the OEM to delete the temp tablespace that was very large. I then tried to create a new one, but, I get an error saying the filesystem is 100% full still. The file is gone and nothing seems to be trying to access it. How can I force the OS to revisit the filesystem and recalculate the actual size? I've tried SAM, lsof, ioscan etc.

[Alan Meyer_4]

what does it say when you perform the following?

fuser /oradata/tmp

[Alex Lavrov.]

It happens when you deleted the file that was in use by some application.

The inode is gone, that's why you don't see the file name in the list, but the allocated space is still there. The only way to clean it is to shutdown the application that uses this space. How?

Use "fuser -k /filesystem" if you wanna kill all the procs there, or use "lsof /filesystem" to view the PID of the procs that uses it and remove the one you think locks the space.

You can get the lsof program here:
http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/lsof-4.75/

Highly recommended program.

Alex.

[Alan Meyer_4]

I would be weary of issuing a fuser -k on the filesystem unless you knew exactly what it was going to kill.

[Mel Burslan]

whichever process that was holding the files you have modified/trimmed, did not exit or restart to release the space you cleared out.

fuser -c /oradata/tmp

will show you the PIDs holding the space "hostage" Unles you can pinpoint which process this was and kill/restart it, you will not see your space freed up in bdf output.

[Sean Dale]

# fuser /oradata/tmp
/oradata/tmp:

#

The command didn't return anything. I cannot kill all processes accessing this filesystem since it is in use for all of our development databases. I would like to kill any process still trying to access the file I removed, but, it doesn't look like anything is accessing it.

[Sean Dale]

If I close then reopen the database I modifed, would that free up the space?

[Pedro Cirne]

Hi,

Yes, if you shutdown/start DB the space will be released, another option is to wait...after some time the space is released (1 or 2 hours...)

Enjoy :)

Pedro

[Sean Dale]

Thanks all!

[Alex Lavrov.]

Once I got an angry email from our senior system administrator:

"DO NOT REMOVE FILES WITH *RM*! Use "cat /dev/null > /some/file"!"

As you can see, very good advice :)

rm, does not remove the file. It only removes the inode. So, when you use "cat /dev/null", you actually empty the file's space and only then you "rm" the inode. This way you can avoid this problem in the future.

Alex.

[Sean Dale]

I will keep that for future reference. However, in this case, the Oracle Enterprise Manager was used to create and delete the file (I assume it also used rm).

[Sean Dale]

I closed the database then repoened it. The filesystem went back down to 14% immediately.

Thanks

[Sean Dale]

problem solved