1

I've known the defintion of %iowait as

Time the CPU spent idling/blocking, because it had to wait on an IO operation to complete.

Now take a simple Linux system with an mdraid1 and two disks. /proc/mdstat shows that the resync is running at about 120MB/s which is close to what you'd expect from a regular spinning SATA disk.

So the speed of the disk is the limiting factor in this case and hence the definition from above I would expect the iowait to be at nearly 100% because that is what keeps the process from finishing in less time.

However that is not the case:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,51    0,00    5,64    0,00    0,00   93,85

There is no iowait whatsoever and the idle time actually suggests to me that the resync could be much faster but just decided it didn't want to (which is not true).

What am I misunderstanding?

dog
  • 168
  • 4
  • If you load the system (so it has to sync stuff) you'll probably see %iowait increase. There's nothing to wait for if you're below the capacity of the disks. – Nathan C May 23 '13 at 17:38

1 Answers1

1

My hypothesis is that because it isn't a proper process (rather something be done by a kernel module) it isn't showing up.

I would guess that the rsync is a function happens within the md kernel module and therefore doesn't actually have a process/thread (task_struct). Because of that, there is no actual linux process waiting on disk in the runqueue (since the resync "job" isn't an actual process) . Since the scheduler will report iowait based on the runqueue, iowait isn't increased by this task.

If you are started an actual process that wanted to use the disk a lot, it would probably wait on disk more because of this resync job, and you iowait would go up. (However, the resync might have a low priority so this still might not happen).

Kyle Brandt
  • 82,107
  • 71
  • 302
  • 444
  • I think this is the case. If you launch a disk intensive process (say MySQL table check or dump) during a md raid rebuild, iowait will typically be very high. I've often had to limit the raid rebuild rate when other processes needed to be completed faster. – jeffatrackaid May 23 '13 at 19:09