I have a Gentoo system with two disk drives. When I run "iostat -d -x -k 15" from sysstat 5.0.5-r1, the second disk, which is idle, shows 100 percent utilization. This is mathematically impossible; an idle disk has zero utilization. Here's a sample of the printout: Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-szavgqu-sz await svctm %util ide/host0/bus0/target0/lun0/disc 1.27 0.40 0.47 1.00 13.33 11.20 6.67 5.60 16.73 1.00 2.73 680.45 99.80 ide/host0/bus0/target0/lun0/part1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 ide/host0/bus0/target0/lun0/part2 0.93 0.00 0.13 0.00 8.53 0.00 4.27 0.00 64.00 0.00 10.00 10.00 0.13 ide/host0/bus0/target0/lun0/part3 0.33 0.40 0.33 1.00 4.80 11.20 2.40 5.60 12.00 0.00 2.00 1.00 0.13 ide/host0/bus0/target1/lun0/disc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 1.00 0.00 0.00 100.00 ide/host0/bus0/target1/lun0/part1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 The line starting with ide/host0/bus0/target1/lun0/disc shows the incorrect data. I'm almost positive this is an upstream problem; I have some Red Hat 8.0 systems where I work that show similar issues. I'm going to send email to the sysstat developer; I can also make this happen with his latest development version, 5.1.something. The kernel is 2.4.26-gentoo-r9; I haven't tried this with a 2.6 kernel, which gets these numbers from a different place.
A little more info: 1. This also shows up in the latest (5.1.3) release of sysstat 2. It is a known (at least to the author of sysstat) issue resulting from the way the 2.4 kernel counts "I/O operations in flight". This number can become negative because of defective logic. I'm not sure if a patch has ever been developed; the last reference I saw on the Linux Kernel Mailing List was about a year old. 3. I may have a workaround for utilizations, but some of the other values are also messed up. Once I hear from the "sysstat" author, I'll see if the workaround is legitimate. 4. I haven't tried it with 2.6 ... I will over the weekend. 5. I think I'll poke the kernel mailing list about this; it's been at least a year since the problem was reported there and it ought to get fixed! If you want to re-classify this as a 2.4 kernel issue, go ahead. If it works on 2.6, you can mark it "fixed in the next release" :)
Nothing we can do, if 2.6 works why not bug the upstream kernel developers to possibly get this backported (or fixed if 2.6 fails too) at http://bugme.osdl.org...? Thanks!
