topic Re: /var displaying incorrect disk usage in Operating System - HP-UX

/var displaying incorrect disk usage

Mike_Ca Li — Fri, 14 Mar 2003 17:17:56 GMT

SCLEDI:/var {406}> du -sk
46486 .
SCLEDI:/var {407}> df -k /var
/var (/dev/vg00/lvol8 ) : 507302 total allocated Kb
75072 free allocated Kb
432230 used allocated Kb
85 % allocation used
SCLEDI:/var {408}> bdf /var
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol8 512000 432229 75073 85% /var

why is du and bdf showing different values and how to fix? Thanks.

Re: /var displaying incorrect disk usage

Pete Randall — Fri, 14 Mar 2003 17:23:07 GMT

A very common question with two possible answers. Either a file was removed but a process still has it open - therefore the space hasn't been re-claimed yet - OR - sparse files, where a section is written and then the program seeks further into the file and writes again - like databases, for example.

Pete

Re: /var displaying incorrect disk usage

erics_1 — Fri, 14 Mar 2003 17:23:42 GMT

Mike,

What you're seeing is a difference in how bdf and du report information. du shows disk space in a more positive light than bdf. You'll see this difference if you've recently deleted files but bdf will eventually 'catch up' and report in line with du. Take a look at knowledge base doc #TBRIXKBRC00001367 for more information.

Best Regards,
Eric

Re: /var displaying incorrect disk usage

Bill Hassell — Fri, 14 Mar 2003 17:40:40 GMT

The space used by a file can be a bit tricky to define. For simple files, the space used is straightforward, but space used by a sparse file is unique. A sparse file is one that has been created with 'holes' or unwritten parts. Consider writing a file with record #1, then by seeking to record one million, writing another record and then closing the file. The file has but two records and occupies only a couple of blocks but the missing parts are not stored nor counted in bdf(1) or du(1). Depending on the size of the file and the spareseness, the difference in apparent versus actual size may be quite large.

To locate sparse files, you must search for files where the difference is quite large between wc -c and the du(1) command. The du(1) command reads the file's disk space from the directory entries and would represent actual space on the disk. wc -c will read the file sequentially, and the filesystem will supply the missing data records as a stream of zeros. On tapes where compression is not available, the space used on the tape will be much more than the apparent disk space.

It is possible to create a sparse file with:

dd if=/etc/issue of=/var/tmp/sparse bs=2048k seek=1

where you will see the original file is just a few dozen bytes, the result with ls -l or wc -c shows a 2 meg file, but du(1) will show the file as occupying just a bit more than the original /etc/issue file. A cp(1) of the file will create a new file that is the same size (using ls -l or wc -c) but du(1) will now show a much larger size.

A common file that is often sparse is a core file from a crashed program. Another file that might be a sparse is /usr/lib/aliases.pag
(or /etc/mail/aliases.pag for 10.xx). And of course, any programmer could write special code that creates a sparse file.

bdf also shows inconsistent results for vxfs mount points versus the corresponding device file. For the HFS filesystem, inodes and superblocks are preset via newfs but for the Journaled File System there are no fixed inode locations. Instead, VxFS filesystems consist of a number of dynamic attributes that describe the filesystem. These dynamic attributes are called structural files and they are kept in a separate fileset (Fileset 1) from the user files (Fileset 999).

Since these structures are dynamic and can grow as more files are added to the filesystem, it is impossible to determine how much space will be used used by structural files and how much space will be used by user files. Unlike an HFS filesystem, where all the inodes are preallocated when the filesystem is created, a VxFS filesystem can continue to allocate more inodes as needed. However, each time a new block of inodes is allocated, the number of actual data blocks are reduced.

So bdf and du must guess as to the number of inodes that might be needed and the space available. The bdf 'used' column represents
space used by both user files and structural files. The bdf 'avail' column represents the Kbytes available after subtracting the actual Kbytes used and the estimated Kbytes needed for inodes.

Re: /var displaying incorrect disk usage

Mike_Ca Li — Fri, 14 Mar 2003 17:52:36 GMT

Thanks for the replies.
Using HPUX 11.11
Pete:
Server not be rebooted since Dec8/2002
If I reboot bdf will show about 47 MB used?

Eric: Could not find TBRIXKBRC00001367, please include link in reply.

Bill: Good suggestion about sparse files
I looked for core files and found only a directory /var/opt/cifsclient/core
Thanks for the algoritm. But is there a script available to locate sparse file so that I don't have to reinvent the wheel.

Re: /var displaying incorrect disk usage

Bill Hassell — Fri, 14 Mar 2003 19:23:25 GMT

No, it's not possible to locate a sparse file without copying it to see if undefined records turn into zeros and make the copy larger. You probably don't want to search for sparse files (as if they were bad things). After all, most all database programs create sparse files for the database.

Re: /var displaying incorrect disk usage

Pete Randall — Fri, 14 Mar 2003 19:31:46 GMT

Mike,

Yes, it's entirely possible, but not guaranteed, that a reboot may fix this discrepancy. This assumes of course that it *IS* an open process situation rather than a sparse file situation.

Pete

Re: /var displaying incorrect disk usage

Martin Johnson — Fri, 14 Mar 2003 20:08:50 GMT

Here is a similar thread I had:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x87c83a7b3682d611abdb0090277a778c,00.html

HTH
Marty

Re: /var displaying incorrect disk usage

Mike_Ca Li — Mon, 17 Mar 2003 15:44:22 GMT

SCLEDI:/var {130}> du -sk
57014 .
SCLEDI:/var {131}> df -k /var
/var (/dev/vg00/lvol8 ) : 484096 total allocated Kb
422983 free allocated Kb
61113 used allocated Kb
12 % allocation used
SCLEDI:/var {132}> bdf /var
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol8 512000 61113 422983 13% /var
SCLEDI:/var {133}> who -r
. run-level 3 Mar 15 07:05 3 0 S

I rebooted that box on Saturday and the big difference on results of du and bdf is gone.
Is there a script available to find which processes still holding the disk space and which bdf still shows used even though the space already cleared?

Re: /var displaying incorrect disk usage

Pete Randall — Mon, 17 Mar 2003 15:49:43 GMT

You could look into a utility called lsof (as in ls open files), available here (among other places):

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/lsof-4.64/

Pete

Re: /var displaying incorrect disk usage

Steven E. Protter — Mon, 17 Mar 2003 15:50:07 GMT

/var is the hardest place to get an accurate snapshot under any circumstances.

At any time, there is data being added to log files such as /var/adm/syslog/syslog.log and lots of other ones.

Every time a user su's it gets logged. Depending on logging level set , every time a user logs in via ftp, it gets logged. This changes file sizes and the results of your query, which obviously uses two very different ways of calculating desk space.

SEP