Bug 132256

Summary: /proc/partitions showing incorrect information
Product: Red Hat Enterprise Linux 3 Reporter: Duncan Innes <duncan>
Component: kernelAssignee: Peter Staubach <staubach>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: petrides
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-04-12 19:27:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Duncan Innes 2004-09-10 12:34:18 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686) Gecko/20040319 Galeon/1.3.7

Description of problem:
When monitoring the statistics in /proc/partitions for the disks on my
system, I find that the data for ruse, wuse and aveq don't appear to
be rolling over at the 32-bit unsigned integer limit.

They appear to be rolling over at a figure 100 times lower than the
limit.  Is this correct?

Version-Release number of selected component (if applicable):
kernel-hugemem-2.4.21-15.0.4.EL

How reproducible:
Always

Steps to Reproduce:
1. set up a cron job to append /proc/partitions to the end of a log
file every minute.
2. Set of some heavy disk load task (mine moves multiple loads of 2Gb
around the various disks on our system)
3. Investigate log file looking at the ruse, wuse and aveq columns

    

Actual Results:  The ruse, wuse and aveq figures roll over at a level
100 times lower than the 32-bit unsigned limit.

Expected Results:  Expect all figures to roll over at the 32-bit
unsigned integer limit (except "running" which is not a counter)

Unless I am mistaken of course.  But the only description of the
/proc/partitons data that I've been able to find states that the
counters all roll over at the 32-bit unsigned integer limit.

Additional info:

Example of my /proc/partitions data:

[root@wwllnx0001 root]# cat /proc/partitions
major minor  #blocks  name     rio rmerge rsect ruse wio wmerge wsect
wuse running use aveq
 
  58     0    2097152 lvma 0 0 0 0 0 0 0 0 0 0 0
  58     1   16777216 lvmb 0 0 0 0 0 0 0 0 0 0 0
  58     2    8290304 lvmc 0 0 0 0 0 0 0 0 0 0 0
  58     3   54341632 lvmd 0 0 0 0 0 0 0 0 0 0 0
  58     4   16777216 lvme 0 0 0 0 0 0 0 0 0 0 0
  58     5  142245888 lvmf 0 0 0 0 0 0 0 0 0 0 0
  58     6   37564416 lvmg 0 0 0 0 0 0 0 0 0 0 0
  58     7   10485760 lvmh 0 0 0 0 0 0 0 0 0 0 0
  58     8    4194304 lvmi 0 0 0 0 0 0 0 0 0 0 0
  58     9   16777216 lvmj 0 0 0 0 0 0 0 0 0 0 0
  58    10    4194304 lvmk 0 0 0 0 0 0 0 0 0 0 0
  58    11   16777216 lvml 0 0 0 0 0 0 0 0 0 0 0
  58    12   71118848 lvmm 0 0 0 0 0 0 0 0 0 0 0
 105     0   35561280 cciss/c1d0 94527 440356 3916694 2346830 742161
764052 12150750 35658510 0 3150280 38008950
 105     1     130544 cciss/c1d0p1 929 58057 117972 17720 34 47 166
1360 0 7570 19080
 105     2   10901760 cciss/c1d0p2 93440 381519 3796846 2328630 742127
764005 12150584 35657150 0 3142910 37989400
 105     3    2044080 cciss/c1d0p3 11 57 136 40 0 0 0 0 0 40 40
 105     4          1 cciss/c1d0p4 2 0 4 10 0 0 0 0 0 10 10
 105     5    2044064 cciss/c1d0p5 11 57 136 20 0 0 0 0 0 20 20
 105     6    2044064 cciss/c1d0p6 11 57 136 30 0 0 0 0 0 30 30
 105     7    2044064 cciss/c1d0p7 11 57 136 30 0 0 0 0 0 30 30
 105     8    2044064 cciss/c1d0p8 11 57 136 30 0 0 0 0 0 30 30
 105     9    2044064 cciss/c1d0p9 11 57 136 30 0 0 0 0 0 30 30
 105    10    2044064 cciss/c1d0p10 11 57 136 40 0 0 0 0 0 40 40
 105    11    2044064 cciss/c1d0p11 11 57 136 20 0 0 0 0 0 20 20
 105    12    2044064 cciss/c1d0p12 11 57 136 40 0 0 0 0 0 40 40
 105    13    2044064 cciss/c1d0p13 11 57 136 20 0 0 0 0 0 20 20
 105    14    2044064 cciss/c1d0p14 11 57 136 50 0 0 0 0 0 50 50
 105    15    2044064 cciss/c1d0p15 11 57 136 40 0 0 0 0 0 40 40
 104     0   35561280 cciss/c0d0 1066586 3079820 33169214 536492
11195311 95541663 855380448 32352570 0 27464537 33401672
 104     1   35561264 cciss/c0d0p1 1066574 3079760 33169070 536512
11195311 95541663 855380448 32352790 0 27464507 33414492
 104    16   71126640 cciss/c0d1 266922 1123597 11120282 34297831
13553100 92209165 847698432 40541491 0 15884157 32266609
 104    17   71126624 cciss/c0d1p1 266910 1123537 11120138 34297791
13553100 92209165 847698432 40541671 0 15884117 32275169
 104    32   71126640 cciss/c0d2 1200735 26785086 223882524 10176765
7011520 133677025 1126657048 6040136 0 16233777 16577022
 104    33   71126624 cciss/c0d2p1 1200723 26785026 223882380 10176755
7011520 133677025 1126657048 6040176 0 16233747 16577042
 104    48  142253280 cciss/c0d3 980181 27461999 227532058 3767854
4814297 129221605 1073518312 34450394 0 4967177 38353758
 104    49  142253264 cciss/c0d3p1 980169 27461939 227531914 3767834
4814297 129221605 1073518312 34450484 0 4967137 38350508
 104    64   71126640 cciss/c0d4 235881 3751049 31891158 15702374
8819205 205909885 1720470352 10294090 0 22312997 26317154
 104    65   71126624 cciss/c0d4p1 235869 3750989 31891014 15702364
8819205 205909885 1720470352 10294320 0 22312977 26326644

Comment 2 Duncan Innes 2004-09-18 15:24:11 UTC
Just an additional note:

This bug has been entered mainly in the hope of getting 32 or 64 bit
unsigned integers used for all the counters in the /proc system.

However, a good start would be a pointer to some documentation on what
is currently in these files.

I searched high and low for info on the /proc/partitions file, but
found very little in the way of documentation.  None of what I found
was concrete in it's explanations.

Comment 3 Doug Ledford 2005-10-18 02:07:17 UTC
Stephen knows more about this than I do, reassigning.

Comment 4 Duncan Innes 2006-02-05 11:30:24 UTC
Stephen,

Do you remember Steven Wallace from school at Heriots?  He says hello.

Anyway, I've been in a position to do some stats using /proc/partitions under
the 2.6 kernels and things appear to have changed (I'm not just talking about
the layout of the files in /proc either).

The graphs no longer show massive spikes of activity that happen when the
counter trips over it's limits.  I've not managed to do any serious disk
hammering tests however, so it could just be that the limits have been raised to
64-bit counters and I haven't reached the limits yet.

Is there any information on these counters?

Thanks

Duncan Innes