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):

enter image description here

  • Is this with data=journal? – DepressedDaniel Feb 9 '17 at 0:00
  • @DepressedDaniel not sure what you mean. I just used iotop -oP – Sparkler Feb 9 '17 at 0:01

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.

| improve this answer | |
  • 2
    Which other disk io categories are there besides journal updates? (i.e. why jdb2 is not the only entry in iotop's output?) – Sparkler Feb 9 '17 at 1:33
  • @Sparkler There's writing the actual data, as well. (Unless you're using a log-structured filesystem, but most aren't.) – Gilles 'SO- stop being evil' Feb 9 '17 at 10:25
  • That explains what happens. But it sucks big time when the original process' I/O priority has been set to 'idle' and jbd2 just continues doing lots of I/O at its own I/O priority. – jlh Dec 31 '18 at 17:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.