Isso não é realmente uma resposta, pois não há contexto suficiente para explicar a causa exata, mas é uma descrição de como consegui acompanhar isso quando aconteceu comigo.
Percebi que meu jbd2/md0-8 continuava aparecendo no topo de iotop . Eu olhei em /sys/kernel/debug/tracing/events/jbd2 para ver quais opções existem para determinar o que o jbd2 estava fazendo.
NOTA-1: Para ver a saída dos eventos de rastreio de depuração cat /sys/kernel/debug/tracing/trace_pipe - Eu tive esta execução no terminal enquanto ativava / desativava os rastreios.
NOTA-2: Para permitir que eventos para rastreamento usem, e. %código%. Para desativar echo 1 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable .
Comecei ativando echo 0 > /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable - mas não havia nada que parecesse particularmente interessante na saída para ele. Tentei alguns outros eventos para rastrear e quando habilitei /sys/kernel/debug/tracing/events/jbd2/jbd2_run_stats/enable vi que estava ocorrendo a cada segundo:
# cat /sys/kernel/debug/tracing/trace_pipe
...
jbd2/md0-8-2520 [004] .... 658660.216492: jbd2_commit_flushing: dev 9,0 transaction 32856413 sync 0
jbd2/md0-8-2520 [001] .... 658661.334900: jbd2_commit_flushing: dev 9,0 transaction 32856414 sync 0
jbd2/md0-8-2520 [001] .... 658661.394113: jbd2_commit_flushing: dev 9,0 transaction 32856415 sync 0
Parecia que isso estava relacionado a /sys/kernel/debug/tracing/events/jbd2/jbd2_commit_flushing/enable / sync(2) / fsync(2) , então procurei um meio de vinculá-lo a um processo e descobri o seguinte:
# find /sys/kernel/debug/tracing/events/ | grep sync.*enable
...
/sys/kernel/debug/tracing/events/ext4/ext4_sync_file_enter/enable
...
Quando ativei, vi a seguinte saída:
# cat /sys/kernel/debug/tracing/trace_pipe
...
nzbget-17367 [002] .... 658693.222288: ext4_sync_file_enter: dev 9,0 ino 301924373 parent 301924357 datasync 1
jbd2/md0-8-2520 [001] .... 658693.284080: jbd2_commit_flushing: dev 9,0 transaction 32856465 sync 0
nzbget-17367 [000] .... 658693.334267: ext4_sync_file_enter: dev 9,0 ino 301924357 parent 301924353 datasync 1
jbd2/md0-8-2520 [002] .... 658693.334275: jbd2_commit_flushing: dev 9,0 transaction 32856466 sync 0
nzbget-17367 [001] .... 658694.369514: ext4_sync_file_enter: dev 9,0 ino 301924367 parent 301924357 datasync 1
jbd2/md0-8-2520 [002] .... 658694.414861: jbd2_commit_flushing: dev 9,0 transaction 32856467 sync 0
nzbget-17367 [001] .... 658694.470872: ext4_sync_file_enter: dev 9,0 ino 301924357 parent 301924353 datasync 1
jbd2/md0-8-2520 [002] .... 658694.470880: jbd2_commit_flushing: dev 9,0 transaction 32856468 sync 0
Isso me deu o nome do processo / id - e depois de fazer mais algumas depurações desse processo ( msync(2) ) eu descobri que estava fazendo nzbget a cada segundo. Depois que eu mudei sua configuração ( fsync(2) , indocumentado acho, achei na fonte) para parar de fazer isso por segundo FlushQueue=no o problema foi embora.
Minha versão do kernel é fsync(2) .Eu acho que havia algumas opções que habilitei (manualmente ou com 4.4.6-gentoo ) em algum momento na configuração do kernel para obter make oldconfig com esses eventos - então se você não tiver talvez só procure na internet mais informações sobre como ativá-lo.