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).
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
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
Were are seeing the same type of abnormal value size behavior with iostat for the avgqu-sz where it shows as 42949662.96
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).
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.
Opened new Bug 113403