Bug 112662 - Disk /proc/stat output seems to be incomplete (2.4.22-1.2135.nptlsmp)
Disk /proc/stat output seems to be incomplete (2.4.22-1.2135.nptlsmp)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-26 14:08 EST by Bryce
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-29 15:52:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bryce 2003-12-26 14:08:09 EST
Description of problem:

This all relates to iostat and /proc/stat under kernel
2.4.22-1.2135.nptlsmp

I've a system that has 6 disks as follows

4x300Gb IDE (hda-d)
1x250Gb SATA (sdb)
1x37Gb  SCSI (sda)

From the system bootup messages:



It detects the 4 IDE drives fine,..
-----------------------------------
ICH5: IDE controller at PCI slot 00:1f.1
ICH5: chipset revision 2
ICH5: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA
hda: Maxtor 5A300J0, ATA DISK drive
hdb: Maxtor 5A300J0, ATA DISK drive
blk: queue c0496600, I/O limit 4095Mb (mask 0xffffffff)
blk: queue c049674c, I/O limit 4095Mb (mask 0xffffffff)
hdc: Maxtor 5A300J0, ATA DISK drive
hdd: Maxtor 5A300J0, ATA DISK drive
blk: queue c0496a74, I/O limit 4095Mb (mask 0xffffffff)
blk: queue c0496bc0, I/O limit 4095Mb (mask 0xffffffff)



It finds the SCSI drive fine,...
-----------------------------------
SCSI subsystem driver Revision: 1.00
scsi0 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.10
        <Adaptec AIC7902 Ultra320 SCSI adapter>
        aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz,
512 SCBs

scsi1 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.10
        <Adaptec AIC7902 Ultra320 SCSI adapter>
        aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI 33 or 66Mhz,
512 SCBs

blk: queue c29c9a18, I/O limit 4095Mb (mask 0xffffffff)
(scsi0:A:0): 320.000MB/s transfers (160.000MHz DT|IU|QAS, 16bit)
  Vendor: SEAGATE   Model: ST336753LW        Rev: 0006
  Type:   Direct-Access                      ANSI SCSI revision: 03
blk: queue c29c9818, I/O limit 4095Mb (mask 0xffffffff)
scsi0:A:0:0: Tagged Queuing enabled.  Depth 32
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sda: 71687372 512-byte hdwr sectors (36704 MB)
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >



It finds the SATA drive fine,...
-----------------------------------
libata version 0.81 loaded.
ata_piix version 0.95
PCI: Setting latency timer of device 00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 18
ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 18
ata1: dev 0 cfg 49:2f00 82:7c6b 83:7f09 84:4003 85:7c69 86:3e01
87:4003 88:207f
ata1: dev 0 ATA, max UDMA/133, 490234752 sectors (lba48)
ata1: dev 0 configured for UDMA/133
ata2: SATA port has no device. disabling.
ata2: thread exiting
scsi2 : ata_piix
scsi3 : ata_piix
  Vendor: ATA       Model: Maxtor 7Y250M0    Rev: 0.81
  Type:   Direct-Access                      ANSI SCSI revision: 05
Attached scsi disk sdb at scsi2, channel 0, id 0, lun 0
SCSI device sdb: 490234752 512-byte hdwr sectors (251000 MB)
 sdb: sdb1



HOWEVER,...
when I was looking through the iostats I discovered that it was
kicking out stats on only 4 drives

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
dev3-0            0.00         0.00         0.00          0          0
dev3-1            0.00         0.00         0.00          0          0
dev8-0            0.00         0.00         0.00          0          0
dev8-1            0.00         0.00         0.00          0          0

I pulled dows the src for iostats (sysstat) and went hunting through
it, to find out that it was pulling out information directly from
/proc/stat. Looking at /proc/stat I found that it was only kicking out
the following

[root@ZenIV sysstat-4.0.7]# cat /proc/stat
... disk_io: (3,0):(33,32,392,1,8) (3,1):(36,35,408,1,8)
(8,0):(70759,60152,836256,10607,284666)
(8,1):(289632,222,2186,289410,39552880) 

where did (3,2) and (3,3) go?

I looked into fs/proc/proc_misc.c (+350ish lines) where the code
fragment for printing out the values in /proc/stat resides.

         proc_sprintf(page, &off, &len, "\ndisk_io: ");
         for (major = 0; major < DK_MAX_MAJOR; major++) {
                 for (disk = 0; disk < DK_MAX_DISK; disk++) {
                         int active = kstat.dk_drive[major][disk] +
                                 kstat.dk_drive_rblk[major][disk] +
                                 kstat.dk_drive_wblk[major][disk];

humm,...
I then added in some proc_sprintf's to see what values were being
passed, however that wasn't very conclusive beyond just confirming
that the kstat.dk_drive* structure didn't have any stats for those
devices.

....
Major = >03< Disk = >00<
kstat.dk_drive[major][disk] = 0x001f
kstat.dk_drive_rblk[major][disk] = 0x0140
kstat.dk_drive_wblk[major][disk] = 0x0008
(3,0):(31,30,320,1,8) 
Major = >03< Disk = >01<
kstat.dk_drive[major][disk] = 0x0016
kstat.dk_drive_rblk[major][disk] = 0x00d8
kstat.dk_drive_wblk[major][disk] = 0x0008
(3,1):(22,21,216,1,8) 
Major = >03< Disk = >02<
kstat.dk_drive[major][disk] = 0x0000
kstat.dk_drive_rblk[major][disk] = 0x0000
kstat.dk_drive_wblk[major][disk] = 0x0000

Major = >03< Disk = >03<
kstat.dk_drive[major][disk] = 0x0000
kstat.dk_drive_rblk[major][disk] = 0x0000
kstat.dk_drive_wblk[major][disk] = 0x0000
....
Major = >08< Disk = >00<
kstat.dk_drive[major][disk] = 0x17a3
kstat.dk_drive_rblk[major][disk] = 0x12110
kstat.dk_drive_wblk[major][disk] = 0x8f82
(8,0):(6051,3776,74000,2275,36738) 
Major = >08< Disk = >01<
kstat.dk_drive[major][disk] = 0x003e
kstat.dk_drive_rblk[major][disk] = 0x035a
kstat.dk_drive_wblk[major][disk] = 0x0020
(8,1):(62,58,858,4,32) 
....


Now the way I read the code, I'm expecting output for 3,2 and 3,3
however the kernel structure doesn't seem to be filled out for these
devices.

I did think that perhaps the 3,0 and 3,1 entries were perhaps both
disks on the same channel being counted as one but thats rules out
when catting one of the drives to /dev/null as none of the counters
are updated.

I'd hunt this down further if I understood where and how the
kstat.dk_drive* structures were manipulated but alas thats outside my
knowledge as it degenerates into a mess of MACROS.

Actually a grep -r shows up two possible areas,..
drivers/block/ll_rw_blk.c:712            
drivers/md/md.c:3386




Current results:
avg-cpu:  %user   %nice    %sys   %idle
           0.00    0.00    9.50   90.50

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
dev3-0            0.00         0.00         0.00          0          0
dev3-1          726.00     92928.00         0.00      92928          0
dev8-0            0.00         0.00         0.00          0          0
dev8-1            0.00         0.00         0.00          0          0

Expected results:
avg-cpu:  %user   %nice    %sys   %idle
           0.00    0.00    9.50   90.50

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
dev3-0            0.00         0.00         0.00          0          0
dev3-1          726.00     92928.00         0.00      92928          0
dev3-2            0.00         0.00         0.00          0          0
dev3-3            0.00         0.00         0.00          0          0
dev8-0            0.00         0.00         0.00          0          0
dev8-1            0.00         0.00         0.00          0          0


Phil
=--=
Comment 1 David Lawrence 2004-09-29 15:52:47 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.