Simpler Navigation for Servers and Operating Systems - Please Update Your Bookmarks
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
If you have bookmarked forums or discussion boards in Servers and Operating Systems, we suggest you check and update them as needed.
Showing results for 
Search instead for 
Did you mean: 

bdf and du differing

Go to solution

bdf and du differing


I have a file system full on my system on /var

# bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 204800 86104 117816 42% /
/dev/vg00/lvol1 295024 45160 220360 17% /stand
/dev/vg00/lvol8 1298432 1298432 0 100% /var
/dev/vg00/lvol7 1581056 1043912 533032 66% /usr
/dev/vg00/lvol4 204800 33584 169936 17% /tmp
/dev/vg00/lvol6 1236992 1185672 50984 96% /opt
/dev/vg00/lvol5 2097152 1127048 962656 54% /home

i tried to get the culprits for this and see if i can delete the files by using

du -akr /var | sort -n -k 1,1

and delte the appropriate files.

but when i do du -s /var itself, i find the output of bdf.

# du -s /var
276752 /var

My unix version is as follows.
# uname -a
HP-UX braces B.11.11 U 9000/800 2002499995 unlimited-user license

Your help in solving my issue would be highly appreciated
Patience pays....but you will need pateince for that........
Honored Contributor

Re: bdf and du differing

Steven E. Protter
Exalted Contributor

Re: bdf and du differing


The difference between bdf and du involve how they report files handles locked where the file is deleted.

If you delete a file to save space but there is still an open file handle, bdf will not report the space as released because in fact it is not released.

du will under the same circumstances report different free space.

bdf is not based on du and does it calculations differently.

It is quite frequent that files in the /var system will be locked because they are log files and syslog and other deamons need to keep them locked.

You might find that stopping and starting the syslog daemon will release the space.

/sbin/init.d/syslogd stop
/sbin/init.d/syslogd start

If you have deleted or trimmed log files manually tell us what their names are and we can identify which daemon needs to be stopped in order to have the space clear.

Steven E Protter
Owner of ISN Corporation
Andrew Young_2
Honored Contributor

Re: bdf and du differing


There are three comments I need to make.

Firstly there if any files have open file handles (ie they are in use) they will only be deleted once they have been closed. A classic example are syslogd files /var/adm/syslog/syslog.lod and /var/adm/syslog/maillog.

If you know which files they are you can send a Hang UP signal to the process which will close those files and reopen them. Use the following command kill -s SIGHUP where PID is the process ID. Use the ps command to identify the process ID's

The second is that the software installer keeps old versons of files that have been patched in /var/adm/sw which often take up a lot of space. Do not simply delete these files. You can clean up (remove) superseded patches - patches that themselves been replaced by newer patches - using the cleanup -c command. For more details see man cleanup .

There are also log files in /var/adm/sw which can be removed.

If you running omniback there may be more files you can remove in /var/opt/omni/log or /var/opt/omni/server/log.

There may also be files in the spool folder for mail and printers. lpstat will give you the print queue contents and mailq the sendmail mail queue. You cannot just delete files from these folders though.

Lastly bdf has a habit of caching entries so be careful that it may not pick up changes in file system size after deletions. Sometimes you need to open a new shell first. I'm not about du though.

Perhaps a good place to start would be to see where the large users of /var are.

Run du -ks /var/*


Andrew Y

Si hoc legere scis, nimis eruditionis habes
John Dvorchak
Honored Contributor

Re: bdf and du differing

When I have a file system either filled or filling I use the following to print the culprits at the top of the list including the subdirectory name:

du -kxa /var | sort -rn | more

The du -k (kilobytes) x (don't cross to another file system) a (print all files) then pipe it to sort -r (reverse)n (numeric) and since it will give me the biggest offenders first I pipe it to more to pagenate the output.

Using this system you will know which directory is using the most space because somethimes there can be hundreds of small files that take up as much space or more that some large "log" files etc.

Here is a sample and note that the biggest user of disk space is /var/adm/sw/save directory followed by /var/adm/sw/products directory the largest single file being /var/adm/sw/save/PHCO_35291

root> du -kxa /var |sort -rn |more
771304 /var
689368 /var/adm
684328 /var/adm/sw
530168 /var/adm/sw/save
131344 /var/adm/sw/products
116120 /var/adm/sw/save/PHCO_35291
114720 /var/adm/sw/save/PHCO_35291/VXVM-RUN
64192 /var/opt
62880 /var/adm/sw/save/PHSS_33944
62208 /var/adm/sw/save/PHCO_35291/VXVM-RUN/etc/vx
62208 /var/adm/sw/save/PHCO_35291/VXVM-RUN/etc
41088 /var/adm/sw/save/PHCO_35291/VXVM-RUN/usr
38352 /var/opt/perf
37464 /var/opt/perf/datafiles
33656 /var/adm/sw/save/PHSS_32977
32648 /var/adm/sw/save/PHCO_35291/VXVM-RUN/etc/vx/type
31152 /var/adm/sw/save/PHSS_33949
29712 /var/adm/sw/save/PHCO_35291/VXVM-RUN/usr/sbin
29376 /var/adm/sw/save/PHCO_35291/VXVM-RUN/etc/vx/static.d
28688 /var/adm/sw/save/PHCO_35291/VXVM-RUN/etc/vx/static.d/build/vold.o
28688 /var/adm/sw/save/PHCO_35291/VXVM-RUN/etc/vx/static.d/build
25184 /var/adm/sw/save/PHSS_33944/LANG-64ALIB/usr/lib/pa20_64
25184 /var/adm/sw/save/PHSS_33944/LANG-64ALIB/usr/lib

If it has wheels or a skirt, you can't afford it.
Respected Contributor

Re: bdf and du differing

take a look at doc TBRIXKBRC00001367

if the link does not work here is what's in it


The filesystem has filled up, so action was taken to delete 800MB of logfiles.

The command:
"du -s"

shows the space as 'freed' but "bdf" doesn't. How can that be?


hpux 10.x 10.20 11.x s700


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
blocks 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.
The tongue weighs practically nothing, but so few people can hold it

Re: bdf and du differing

Thanks a lot for all of your answers.
I actually i tried to clean up some of the files...
bdf for a brief moment displayed some free space but very quickly made that to "zero".
Then i suspected that it is indeed some process that is culprit.

I found that i have two "seagulls" running on my system and that is causing the havoc.. I killed both and now have a 10% utilization on my /var.

Thanks again for your time and the immense patience in explaining the very basic things also.
Patience pays....but you will need pateince for that........

Re: bdf and du differing

I found a solution largely due to the suggestion by Aussan but all the inputs from the other "Pundits" helped immensely in understanding the differences between bdf and du and also actions required when the file system is full.
Patience pays....but you will need pateince for that........
Dennis Handly
Acclaimed Contributor

Re: bdf and du differing

You may want to look at this long thread for some more tips:

Your bdf output indicates you aren't as tricky. :-)