[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference turris::digital_unix

Title:DIGITAL UNIX(FORMERLY KNOWN AS DEC OSF/1)
Notice:Welcome to the Digital UNIX Conference
Moderator:SMURF::DENHAM
Created:Thu Mar 16 1995
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:10068
Total number of notes:35879

9579.0. "tbl_dkinfo Disk Stat structure problem" by BLAZER::MIKELIS (Software Partner's Eng. MR01-3/F26) Tue Apr 22 1997 14:17

I have an ISV who reported the following problem while trying to 
capture disk statistics. Is there a patch avail for this problem?


    Company Name :  Landmark Systems Corporation
    Contact Name :  Craig E. Despeaux
    Category     :  unix
    OS Version   :  4.0b

    Brief Description of Problem:
    -----------------------------

I'm issuing the table system call on Digital Unix 3.2 and 4.0B to retrieve
information from the disk statistics table.  The problem is that zeros are
returned for all fields in the tbl_dkinfo structure with the exception of
di_xfer and di_wds on Digital Unix 3.2.  On Digital 4.0B, zeros are returned
for all fields but di_xfer, di_wds, and di_avserv.  The non-zero values are
definitely increasing with each execution of the program, however, they are
the only fields returning non-zero data.  I am certain that the appropriate
index into the table is being used for the disk in question.  Are we missing
something that needs to be configured to turn on collection for the other
disk statistics?   
T.RTitleUserPersonal
Name
DateLines
9579.1NABETH::alanDr. File System's Home for Wayward Inodes.Tue Apr 22 1997 18:4516
	What you are missing is a disk driver that collects all the
	information.  However, since one doesn't exist, there isn't
	much you can do about except file IPMT cases and give product
	managers sales numbers for what the feature is worth.

	For some of the numbers, it may not make sense to collect
	values; di_seek.  None of the storage protocols supported
	by Digital UNIX require an explicit seek to get data.  They
	work by requesting an LBN range.  If the disk has to seek
	to get to the data, that's the disk's problem.  It is quite
	reasonable for that field to be zero.

	Monitor's life would easier if the di_avque had a something
	in it and I've been that told that that is one of the many
	things to be fixed in Steel.  Maybe some of the others will
	be as well.