Я знал определение %iowait так как
Время, в течение которого ЦП простаивал / блокировался, потому что ему приходилось ждать завершения операции ввода-вывода.
Теперь возьмем простую систему Linux с mdraid1 и двумя дисками. /proc/mdstat показывает, что повторная синхронизация выполняется со скоростью около 120 МБ / с, что близко к тому, что вы ожидаете от обычного вращающегося диска SATA.
Таким образом, скорость диска является ограничивающим фактором в этом случае, и, следовательно, исходя из приведенного выше определения, я ожидал бы, что iowait будет почти на 100%, потому что это то, что не позволяет процессу завершиться за меньшее время.
Однако это не так:
avg-cpu: %user %nice %system %iowait %steal %idle
0,51 0,00 5,64 0,00 0,00 93,85
Нет никакого iowait, и время простоя фактически подсказывает мне, что повторная синхронизация может быть намного быстрее, но просто решил, что не хочет (что неверно).
Что я не понимаю?
Моя гипотеза заключается в том, что, поскольку это неправильный процесс (скорее, что-то, что должно выполняться модулем ядра), он не отображается.
Я бы предположил, что rsync - это функция, которая происходит внутри md модуль ядра и поэтому фактически не имеет процесса / потока (task_struct). Из-за этого нет фактического процесса Linux, ожидающего на диске в очереди выполнения (поскольку «задание» повторной синхронизации не является фактическим процессом). Поскольку планировщик будет сообщать о iowait на основе очереди выполнения, эта задача не увеличивает iowait.
Если вы запускаете реальный процесс, который хочет много использовать диск, он, вероятно, будет ждать на диске больше из-за этого задания повторной синхронизации, и вы, iowait, пойдете вверх. (Однако повторная синхронизация может иметь низкий приоритет, поэтому этого может не произойти).