Difference in df and du output

[GSK_2]

Hi Guys,

We are having problem with one mount point which was not refreshing with the correct details in df command. This filesystem is of approximately 100Gb and it was used to 87% which comes around 87GB. Even after deleting more than 60GB it still shows the same details in df even after 2 days time. But where as du -sk shows that it was only 21Gb used. Here are the details:

$ bdf /u50
Filesystem kbytes used avail %used Mounted on
/dev/vgEVA_R5/lvol9
102400000 88238110 13276832 87% /u50

$ pwd
/u50
$ du -sk
21494872 .
$

How can we get the df command to refresh its current details? DO we need to install some patch ? or can this be only reflected with correct details only after rebooting? Please help me find the answer. THanks in advance.

Regards,
Satish

[Ninad_1]

Did you delete the 60 GB worth files while they were still been used by any processes ? If yes, then you can expect such behaviour. You could have checked using fuser if a file is being used by any process before deleting it.
Now if you can take an outage on your application which uses this filesystem, and then do a umount and mount that would give you the results you are expecting.

Regards,
Ninad

[Matti_Kurkela · Accepted solution]

Usually this happens if you deleted files that were in use by some process. In that case, the files vanish from the directory listings, but are not really deleted until that process stops using the files. This is normal Unix behavior.

In this situation, "ll" and "du" don't see the deleted files any more, but "df" will see that disk space is still used by something.

If you have the "lsof" command installed, you can use "lsof +L1" to find the processes that are holding the deleted files open.

If you don't have "lsof" installed, you'll need to use your knowledge of this particular system to find the correct processes - sometimes this is very difficult, so I recommend always installing the "lsof" command. It is available in the HP-UX Porting Archive:
http://hpux.cs.utah.edu/ (US site)
http://hpux.connect.org.uk/ (mirror in UK)
http://hpux.its.tudelft.nl/ (mirror in NL)

Of course, rebooting the server will fix the problem because all processes are stopped and restarted, but it's not needed if you know which process(es) to stop.

Some applications create log files that grow without limit: if these applications are well-designed, they usually have some way to signal the application to close and re-open the log files. This is to allow rotating and cleaning up the log files without stopping the application. If the files you removed are log files, check if your application has this feature.

MK

[Rory R Hammond]

I don't recommend booting the server to fix this problem.

fuser -u on the logical volume will show process id that have files in use.

A keen eye might help you pick out the process that needs stopped and restarted to free up the space.

Example:
On my system /usr/tmpi:

/dev/vg01/lvol18 1572864 980069 557168 64% /usr/tmpi

root:ecom1# fuser -u /dev/vg01/lvol18
/dev/vg01/lvol18: 12737c(root) 27023o(mercator) 520c(root) 15688c(roo
t) 14175c(root)

Fuser shows a userid mercator and root running.
A few ps -fe on process id on 27023 showed me that this was the culprit, and I killed the process.

Rory


Rory