space available

[Juan Pablo Wagner_1]

Hello everybody. Somebody can explain to me so that reason when obtaining the exit of different commands the amount of disc use is different?
/#du -k /usr/sap/PRD
0 /usr/sap/PRD/lost+found
1 /usr/sap/PRD/DVEBMGS00/data/cache
526345 /usr/sap/PRD/DVEBMGS00/data
6253 /usr/sap/PRD/DVEBMGS00/log
3 /usr/sap/PRD/DVEBMGS00/sec
27915 /usr/sap/PRD/DVEBMGS00/work
78597 /usr/sap/PRD/DVEBMGS00/igs/bin
3 /usr/sap/PRD/DVEBMGS00/igs/conf
309 /usr/sap/PRD/DVEBMGS00/igs/data/gfwchart
0 /usr/sap/PRD/DVEBMGS00/igs/data/shapefiles
0 /usr/sap/PRD/DVEBMGS00/igs/data/htdocs
0 /usr/sap/PRD/DVEBMGS00/igs/data/output
310 /usr/sap/PRD/DVEBMGS00/igs/data
0 /usr/sap/PRD/DVEBMGS00/igs/dump
5 /usr/sap/PRD/DVEBMGS00/igs/log
119676 /usr/sap/PRD/DVEBMGS00/igs/lib
0 /usr/sap/PRD/DVEBMGS00/igs/test
201503 /usr/sap/PRD/DVEBMGS00/igs
762019 /usr/sap/PRD/DVEBMGS00
0 /usr/sap/PRD/SYS/exe/opt
0 /usr/sap/PRD/SYS/exe
0 /usr/sap/PRD/SYS/gen/dbg
0 /usr/sap/PRD/SYS/gen/opt
0 /usr/sap/PRD/SYS/gen
0 /usr/sap/PRD/SYS/src
0 /usr/sap/PRD/SYS
762023 /usr/sap/PRD
/#

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

/#bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg01/lvol11 1536000 1402535 125190 92% /usr/sap/PRD

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


/#df -k /usr/sap/PRD
/usr/sap/PRD (/dev/vg01/lvol11 ) : 1527819 total allocated Kb
123774 free allocated Kb
1404045 used allocated Kb
91 % allocation used

[A. Clay Stephenson]

The bdf and df commands are measuring essentially the same things because they operate at the filesystem level (ie reading more at the filesystem internal data level). The small differences in value could easily be simply that the commands were run at slightly different times.

du operates more by counting up the blocks of each file. Notice that the directory /usr/sap/PRD/SYS is given a size of 0 --- that cannot be literally true because even an empty directory occupies some space. However, the biggest differences in the output between du and the other commands result from two things: 1) unlinked files 2) sparse files. When a file is rm'ed (unlink()'ed), the space isn't actually returned to the filesystem until all processes that had the file open either close the file or terminate. This is a common method of creating temporary files. The files are completely usable to any process which had them open but will not be listed anywhere. In this case, du will report a smaller value than df (or bdf) because the space has not been returned to the filesystem. The opposite is true when sparse files are in play. A sparse file might be created by write()'ing 1 block; lseek()'ing to byte offset 1000000, and write()'ing 1 block. This file would occupy 2 blocks from the perspective of df and bdf bu du (or ls -l would say that this file is 1000000 + 1024 bytes long. In fact, sparse files make it possible to actually overcommit a filesystem.

[whiteknight]

hi juan

Agreed with Clay, if you have HP support maintainence contract, you may log call to Response Center obtain crashinfo tool from HP support, you can run crashinfo -unlinked, it will show you the unlinked files, this may help to drill down the issue.


Hope this help.
WK

[Juan Pablo Wagner_1]

thanks