Bug 78749

Summary: sysstat sar report bogus inode-sz information
Product: [Retired] Red Hat Linux Reporter: Peter H.S. <phs123>
Component: sysstatAssignee: Charlie Bennett <ccb>
Status: CLOSED WORKSFORME QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: alz27, gbailey, jim.laverty, nphilipp
Target Milestone: ---   
Target Release: ---   
Hardware: athlon   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-01-13 15:27:51 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 Peter H.S. 2002-11-28 21:39:40 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
/usr/bin/sar -v reports bogus values for the number of used inode handlers
(inode-sz column).

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.run sysstat for a couple of days
2.issue a /usr/bin/sar -v
3.look at the "inode-sz" column: the number suddenly jumps from eg. 2553 to
4294965649.


Additional info:

Here is a reduced sar -v output example:
---
              inode-sz

03:30:00 AM       2295
03:40:00 AM 4294967250
03:50:01 AM         19
04:00:00 AM 4294967275
---
All the abnormal numbers seems to be in the 42949xxxx range.
Someone one a RH mailling list
(http://www.redhat.com/mailing-lists/ext3-users/msg04061.html)
suggested "OK, these counts look like they are going negative: 4 billion is
where unsigned integers wrap round to if you try to decrement them below zero."

The bogus inode-sz values appears on all our RH 7.3 servers too (Intel P4,
Athlon etc).

Comment 1 Need Real Name 2003-03-13 05:59:15 UTC
I see next dependent:
In 04:02 begin work cron.daily. In this part exist slocate.
If i use only slocate in any time, situation repeat.
My things: inode is 'unsigned int'.
kernel use relative 'minus' and go to negative side.
Logs:
03:50:00           56      1526      2,91 4294960156
04:00:00           53      1521      2,90 4294960149
04:10:00        76332      1515      2,89     72485
04:20:00        55176      1524      2,91     48818
04:30:00        38970      1507      2,87     31907
04:40:00        28199      1528      2,91     21951
04:50:00        19912      1533      2,92     14304
05:00:00        13942      1554      2,96      9131
05:10:00         9957      1525      2,91      4944
05:20:00         7130      1515      2,89      1922
05:21:00         7132      1519      2,90      1922
05:22:00         6019      1519      2,90       787
05:23:00         6020      1519      2,90       788
05:24:00         6019      1508      2,88       795
05:25:00         6022      1521      2,90       791
05:26:00         6023      1521      2,90       791
05:27:00         5144      1514      2,89 4294967088
05:28:00         5148      1517      2,89 4294967088
05:29:00         5149      1518      2,90 4294967088
05:30:00         5150      1518      2,90 4294967089
05:40:00         3931      1526      2,91 4294965485


Comment 2 Jim Laverty 2003-03-21 15:27:05 UTC
We're are experiencing the same problem with 2.4.18-5smp:

07:40:01 AM dentunusd   file-sz  %file-sz  inode-sz  super-sz %super-sz 
dquot-sz %dquot-sz  rtsig-sz %rtsig-sz
07:50:00 AM     38086       432      0.11     17279         0      0.00        
0      0.00         1      0.10
08:00:03 AM     38084       416      0.11     17281         0      0.00        
0      0.00         1      0.10
08:10:00 AM     38103       409      0.10     17296         0      0.00        
0      0.00         1      0.10
08:20:00 AM     38103       400      0.10     17295         0      0.00        
0      0.00         1      0.10
08:30:00 AM     38104       399      0.10     17295         0      0.00        
0      0.00         1      0.10
08:40:00 AM     38109       409      0.10     17296         0      0.00        
0      0.00         1      0.10
08:50:00 AM     38108       399      0.10     17295         0      0.00        
0      0.00         1      0.10
09:00:01 AM     38110       399      0.10     17295         0      0.00        
0      0.00         1      0.10
09:10:00 AM     32067       128      0.03     11234         0      0.00        
0      0.00         1      0.10
09:20:00 AM        41       128      0.03 4294942830         0      0.00       
 0      0.00         1      0.10
09:30:00 AM        37       128      0.03 4294942826         0      0.00       
 0      0.00         1      0.10
09:40:00 AM        40       106      0.03 4294942829         0      0.00       
 0      0.00         1      0.10
09:50:01 AM       145        93      0.02 4294942871         0      0.00       
 0      0.00         2      0.20
10:00:00 AM        44       130      0.03 4294942862         0      0.00       
 0      0.00         1      0.10
10:10:00 AM       393        31      0.01 4294943055         0      0.00       
 0      0.00         2      0.20
Average:        19937       440      0.11  70406120         0      0.00        
0      0.00         1      0.10

Comment 3 Jim Laverty 2003-03-31 15:38:04 UTC
Were are seeing the same type of abnormal value size behavior with iostat for
the avgqu-sz where it shows as 42949662.96

Comment 4 Nils Philippsen 2004-01-13 15:27:11 UTC
Closing (no activity, 8.0 EOL). If the problem still shows (on current
versions of RHEL or Fedora Core), please reopen (with appropriate
product/version).

Comment 5 Jim Laverty 2004-01-13 15:54:22 UTC
I forgot about this bug.  This issue still exists in Red Hat 9 using
sysstat-4.0.7-3 (kernel 2.4.20-20.9smp).  It shows the same avgqu-sz size.

I will try to test the sysstat from the Fedora distro when I get home
later tonight.



Comment 6 Jim Laverty 2004-01-13 16:38:17 UTC
Opened new Bug 113403