Почему большая часть дискового ввода-вывода относится к jbd2, а не к процессу, который фактически использует этот ввод-вывод?

При мониторинге дискового ввода-вывода большая часть ввода-вывода относится к jbd2, в то время как исходный процесс, вызвавший высокий уровень ввода-вывода, объясняется гораздо более низким процентом ввода-вывода. Почему?

Вот iotopпример выходных данных (другие процессы с IO <1% опущены):

process io disk

— бенгальский огонь
источник

Это с data=journal?

— ДепрессияДаниэль

@DepressedDaniel не уверен, что вы имеете в виду. Я просто использовал iotop -oP

— Sparkler

jbd2 поток ядра, обновляющий журнал файловой системы

Отслеживание активности файловой системы или диска с процессом, вызвавшим его, затруднено, поскольку действия многих процессов объединены вместе. Например, если два процесса читают из одного и того же файла одновременно, какой процесс будет учитываться при чтении? Если два процесса записывают в один и тот же каталог, и каталог обновляется на диске только один раз (объединяя две операции), какой процесс будет учитываться при записи?

В вашем случае кажется, что большая часть трафика состоит из обновлений журнала. Это прослеживается до средства обновления журнала, но нет никакой трассировки между обновлениями журнала и процессом (ами), который вызвал операцию (записи) записи, которая потребовала этого обновления журнала.

— Жиль "ТАК - перестань быть злым"
источник

Какие есть еще категории дисков, кроме обновлений журнала? (т.е. почему jdb2 не единственная запись в выводе iotop?)

— Sparkler

@ Sparkler Там тоже пишутся реальные данные. (Если только вы не используете файловую систему с лог-структурой, но большинство из них не используют.)

— Жиль "ТАК - перестать быть злым"

Это объясняет, что происходит. Но это отстой, когда исходный процессный приоритет ввода / вывода был установлен на «бездействие», и jbd2просто продолжает выполнять много операций ввода / вывода со своим собственным приоритетом ввода / вывода.

— июля