Wondering about one of our file system size?

[apple]

When we issue bdf, it says that one of our mount point size is 18GB with 17GB used 95 % utilized. But we are very wondering, when we check and add up the content of the file system, the total is only 2.2 GB. attached is the output for bdf and the content of the file system.

Where are all the files hiding that utilized the mount point? We are very surprised, it because of the file system defragmented or something. Looking forward for your advice. Do we need to move the file system and recreate the file system? What is the best solution to resolve this â ghost filesâ that utilized our file system? Hope to hear from you.

[Robert-Jan Goossens · Accepted solution]

Hi,

Probably someone removed an open file.

download and install lsof.

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/lsof-4.78/

# lsof /filesystem
and lo0cate the PID of the open, kill it or restart your app.

HTH,
Robert-Jan

[Jeeshan]

this may be happen if you delete a file but someone/some process still holds that/those files

if possible than, shutdown your oracle box and then see what is the status.

or apply command fuser -cu /mountpoint name that which user is accessing that mount point

[Mounaam]

Install lsof if not present, then:
# lsof +L1

[Mark Ellzey]

As was stated before, it could be an open file that was removed. Just because a file was removed does not mean that some process cannot still write to the filehandle.

It appears that you have a database on this filesystem (the *.db). If that's the case, is could be a 'sparse' file. This is a file where the data is full of 'holes'. It's not something you can 'defragment' because the application created the file this way.

You may want to create a larger volume and move the data to the new volume.

Regards,
Mark

[Paul Sperry]

bet if you rebooted a bdf would show differently. This happens to me with the /tmp filesystem

[Dennis Handly]

>Paul: bet if you rebooted a bdf would show differently.

I assume you mean that rebooting is the same as killing the process that is holding the gigantic file open?

[apple]

very interesting, but how can we avoid the sparse file. currently the file system is occupied by the oracle database files.
we have created the volume based on our dba requirements, i'm not sure how creating the larger volume could solve the problem. it's difficult how big the volume is. would really appreciate your advice. all your responds are very great. thanks a lot. hv a nice day

[Dennis Handly]

>but how can we avoid the sparse file.

Why would you want to do that? Sparse files are good, lots of zeroes are bad. In computer science, entropy == information, order is bad.

>I'm not sure how creating the larger volume could solve the problem.

Having a larger volume would mean it wasn't 95% used.

Have you used lsof(1) to find the open file? That would go a long way to tell you what to do next.

[Yogeeraj_1]

hi again,
>but how can we avoid the sparse file.
Why avoid?? it is supposed to be a OS feature.

When temporary files are created sparse, they will not actually consume disk storage until they need to.


hope this helps!

kind regards
yogeeraj

[apple]

very interesting. ok i have just downloaded the lsof. it's in .depot extension. i just need to swinstall -s /tmp/lsof.depot right?
i'll search from the itrc forum how to best use it. :)

[Dennis Handly]

>i just need to swinstall -s /tmp/lsof.depot right?

You need to specify what you want to install, otherwise it goes into the GUI:
# swinstall -s /tmp/lsof.depot \*