Filesystem show 66% used while it is free

[Has]

Hi ,
I have filesystem on hp-ux 11.23 show 66% used, and it is only have only 4 small files.

bdf
/dev/vgora3/lvolarch 580829184 375993500 192034120 66% /ora/arch

cd /ora/arch
du -ks *
5 ARC_1_5559_627560237.arc
0 lost+found
37 system_info_v7.sh
94 system_info_Oracle.txt

Please advice.
Thanks

[Dennis Handly]

You don't have any hidden "." files (and you're not root) do you?

Otherwise this happens if you had a large file that was opened and then you removed it. The space still stays there until that process is finished.

You can use lsof(1) to find who has it opened.
There are lots of threads on this.

[Avinash20]

Obviously there is a difference in how du and bdf behave.
This may occur if we touch open files.
"du" shows output in a positive view: it shows the number of currently allocated locks and counts the blocks you've just deleted as free.

"bdf" has a more negative perspective: it shows the free disk space available.

The difference is here: if a still-active process has allocated blocks (such as for a logfile that you've just deleted), "bdf" counts these as still occupied.
This won't change until the process closes the file ("deallocates the blocks")
as it usually happens when the process terminates.

[Avinash20]

http://h10025.www1.hp.com/ewfrf/wc/genericDocument?docname=c01072210&cc=us&dlc=en&lc=en&jumpid=reg_R1002_USEN

Download the crashinfo.bin file from the above link for IA or PA.

Once on HP-UX system:
# cd /tmp
# ./crashinfo -v

There may be remarkable differences in the bdf(1) and du(1) outputs, because bdf(1) looks at file system statistics, while du(1) looks at the files it finds in the directories.

Under certain circumstances, files that actually exist in a file system, might not be visible. There are two reasons for that, which are also the reason why du(1) wouldn't count their sizes when calculating the disk usage:

1) files that have already been deleted, but are still opened by running processes

You can find such files with

# /tmp/crashinfo -unlinked

It will print their inodes and sizes, and also the processes that still have this file open, e.g.
[formatted]
PID PPID COMMAND INODE DEVICE SIZE(bytes)
3844 1 swagentd 6725 /dev/vg00/lvol6 133
[unformatted]
These files will still occupy space in the file system, but they will not be visible in the directory listings because their directory entries have already been deleted. The files themselves will only be deleted after all processes that have the file open either close the file, or terminate.

If that doesn't happen on its own, you might need to kill the appropriate processes, to free the disk space by
# kill -9

NOTE: If still there are issue, you need to stop the Database to release the unlinked file

[Rasheed Tamton]

I would go for lsof:

lsof /ora/arch |more

look through the list and kill the process.

rgds.

[jolight]

I support Rasheed, lsof is the best way to check the same.. Some of the process may be hanged in between and filling up the space.

[Jeeshan]

may be some files may be helded over to another programs.

try the above post answer to check which files are still opened that were previously deleted.

[Avinash20]

Hi,

Please refer to the below link which you help you

http://www11.itrc.hp.com/service/cki/docDisplay.do?docLocale=en&docId=emr_na-c01055283-2

[Fabien GUTIERREZ]

the evidence is that a file was removed by rm while it was still opened by another process so it did not free the space
to check which processes are still locking it just issue a lsof on your FS and it ll shows you the processes in cause

[SKR_1]

lsof /ora/arch

This command will give all processes running under this FS.

Kill the processes under the presence of some DBA guys.

Sometimes you rm some bigger files, it takes some times to free up the space.

Thanks