When monitoring disk IO, most of the IO is attributed to jbd2, while the original process that caused the high IO is attributed a much lower IO percentage. Why?
Here's iotop's example output (other processes with IO<1% omitted):
1 Answer
jbd2 is a kernel thread that updates the filesystem journal.
Tracing filesystem or disk activity with the process that caused it is difficult because the activities of many processes are combined together. For example, if two processes are reading from the same file at the same time, which process would the read be accounted against? If two processes write to the same directory and the directory is updated on disk only once (combining the two operations), which process would the write be accounted against?
In your case, it appears that most of the traffic consists of updates to the journal. This is traced to the journal updater, but there's no tracing between journal updates and the process(es) that caused the write operation(s) that required this journal update.
answered Feb 9, 2017 at 0:39
Gilles 'SO- stop being evil'Gilles 'SO- stop being evil'
811k194 gold badges1677 silver badges2178 bronze badges
-
3Which other disk io categories are there besides journal updates? (i.e. why jdb2 is not the only entry in iotop's output?)– SparklerFeb 9, 2017 at 1:33
-
1@Sparkler There's writing the actual data, as well. (Unless you're using a log-structured filesystem, but most aren't.) Feb 9, 2017 at 10:25
-
4That explains what happens. But it sucks big time when the original process' I/O priority has been set to 'idle' and
jbd2just continues doing lots of I/O at its own I/O priority.– jlhDec 31, 2018 at 17:37 -
so the question mutates to: is it possible to patch the kernel to let that magic happen and show the culprit process? :) but in my case seems to be firefox. I am testing all jbd2 processes to idle right now. Dec 1, 2021 at 23:27
data=journal?