Filesystem free space is not releasing completly

[joseph51]

Hi,

I would like to know why the Filesystem free space is not completely releasing even if we remove all the data in that Filesystme ,as shown below I have removed all the data in the directory /oracle/IF1/sapdata1 still the used is showing around 1.3 GB Also the %used =0
After Emptying the FS
================
root@s96cof21:/oracle/IF1/sapdata2 : bdf |grep sapd
/dev/vgsapif1/lvsapdata1IF1
1897922560 1360039 1778027507 0% /oracle/IF1/sapdata1
/dev/vgsapif1/lvsapdata2IF1
1987510272 503740 1862818759 0% /oracle/IF1/sapdata2
root@s96cof21:/oracle/IF1/sapdata2 :

Before Emptying the FS
=================

/dev/vgsapif1/lvsapdata1IF1
1897922560 1714122383 172312774 91% /oracle/IF1/sapdata1
/dev/vgsapif1/lvsapdata2IF1
1987510272 1716805068 253786233 87% /oracle/IF1/sapdata2

===================

Can any one Please tell me what is the logic behind this or why this is not releasing the complete space .And if any data is using this space how can we find out this

[Kenan Erdey]

Hi,

possibly you deleted opened files with other processes. check them with lsof +aL1 /oracle/IF1/sapdata2. find processes ids and if possible kill them

[joseph51]

Hi,
Before deleting the data I have shutdown the DB then fuser . And confirmed that no process is using this directory . after that only I cleared the data .
Now the restoration of DB is done to this directory . So I cannot check this with the command you given

[James R. Ferguson]

Hi:

Disk blocks belonging to a file will not be released until the last process using the file terminates. This is normal UNIX behavior.

This is actually very handy. It is common to open a temporary file and immediately unlink(2) it. The 'unlink' system call is deployed when you do a 'rm' in a shell.

In so doing the above, only the process creating the temporary file has visibility to it thereby providing heightened security if necessary.

In addition, the technique of opening (creating) and immediately unlinking (removing) a file means that a process's cleanup code (either as an epilog procedure or as a signal trap block) doesn't have to bother with removing the temporary file.

Regards!

...JRF...

[joseph51]

Hi , I have one more doubt .

If we calculate the used size and available size of spdata1 FS it will be around 1696GB
and If we substract the total size from this we are getting a difference of 113GB .
I would like to know where this 113GB gone
Please some one clarify this doubts

[James R. Ferguson]

Hi (again) Binu:

> If we calculate the used size and available size of spdata1 FS it will be around 1696GB

How do you "calculate"; what tools?

Regards!

...JRF...

[joseph51]

Just added used (1360039)+ available (1778027507)= Its not equal to the total size . Its giving the value =1779387546 , which has the difference of 113 GB from the Total space assigned

[James R. Ferguson]

Hi (again) Binu:

The presence 'sparse' files will cause 'bdf' to report a value that reflects what the "inflated" sparse file would be (use), whereas 'du' will report only the actual, allocated blocks.

Since these are Oracle filesystems, it is highly likely that you have such sparse files present. Compare your calculations using 'du' and using 'bdf'. Large discrepancies between what the two methods yield suggest the presence of a sparse file.

Regards!

...JRF...

[Dennis Handly]

>if we remove all the data in that filesystem

(More accurately, you delete files, not remove data.)

>JRF: The presence 'sparse' files will cause 'bdf' to report a value that reflects what the "inflated" sparse file would be (use)

Huh? Only ll(1) does that. bdf(1) works correctly.

>Compare your calculations using 'du' and using 'bdf'.

The difference between these is unlinked files, not sparse files.

[James R. Ferguson]

Hi (again):

> ME: Compare your calculations using 'du' and using 'bdf'.

> Dennis: The difference between these is unlinked files, not sparse files.

Yes, indeed. I was thinking that Binu might have summed sizes using 'ls' and thus with sparse files, the 'ls' summation value would be larger than that of 'bdf'. I mangled my second post's point :-(

Regards!

...JRF...