Conflict between df -k and du -sk...again

UNIX HP-UX
1

Hi,
I know this has been discussed a number of time but i could not get the exact answer. So need help again.

Issue:

The two command for same file system shows different size.

du -sk shows toatl size is 12780685 KB while df -k 45289229 used allocated Kb

/oxt/mantran/bin $ du -sk /oxt/mantran/bin/dev_usa
12780685        /oxt/mantran/bin/dev_usa
/oxt/mantran/bin $ df -k /oxt/mantran/bindev_usa
/oxt/mantran/bin/dev_usa (/dev/vg07/lvol2       ) : 
                                                   46103286  total  allocated Kb
                                                   814057     free allocated Kb
                                                    45289229 used allocated Kb
                                                     98 % allocation used

Regards,
Malay:eek:

2

If your problem doesn't match answers supplied elsewhere, it helps to know what you know isn't true and why you know it.

So, we assume that you know your file system doesn't need to be fscked to rebuild the free space? We assume that there are no sparse files that could confuse the issue?

What else? What OS? What filesystem?

Could a deleted file be being held open somewhere?

Could you possibly have union mounts anywhere in here?

3

Hi Tony,

I don't know about fscking to rebuild the space, I need to contact our system administrator for this. This is a HP Unix system.

I neither found any sparse file nor any union mounts anywhere in here.

One more thing I want to add - I am monitoring the folder since last 10 hour. There was very few file came into(total size 2Kb) but the space has been decrease around 4000KB till now.

4

We need more information to help you here...
What so special about this filesystem? (Does it belong to a application, writing logs or...)
What is the output of uname -r?
what does bdf <directory name> gives you for an output?

5

What you you get from:

uname -srm

lvdisplay /dev/vg07/lvol2

bdf /oxt/mantran/bin/dev_usa

This effect is usually caused by processes "deleting" files which are still open. "du" sees the file as gone but "df" and "bdf" are correct.
Can you account for all the processes with:

fuser -u /oxt/mantran/bin/dev_usa
6

1)uname -srm
Output : HP-UX B.11.23 ia64
2) The file system belong to a application. Yes logs are collected there.
3) bdf /oxt/mantran/bin/dev_usa
Output:Filesystem kbytes used avail %used Mounted on
/dev/vg07/lvol2 46137344 42479560 3448226 92% /oxt/mantran/bin/dev_usa

4)lvdisplay /dev/vg07/lvol2
--- Logical volumes ---
LV Name /dev/vg07/lvol2
VG Name /dev/vg07
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV Size (Mbytes) 45056
Current LE 704
Allocated PE 704
Stripes 0
Stripe Size (Kbytes) 0
Bad block on
Allocation strict
IO Timeout (Seconds) default

7

We have eliminated slow syncing of mirrors because there aren't any mirrors.
We have eliminated wrong parameters to "newfs" or "extendfs" because LVM and "bdf" agree.
The usual reason for this discrepancy is that a program or user is deleting files which are open by an application which is still running. Usually in this circumstance "bdf" is right and "du" is wrong.
There are other possible reasons like embryonic files.
Do you get the disc space back after a reboot or application recycle perhaps?

8

Thanks!

Got all the hidden space after the application is recycled.

9

Many times, this issue is produced when somebody delete a file it's open and the application continues writting.

You can see it with:

lsof /mount_point | grep -i deleted

Take in mind lsof is not installed by default.