iotop ascribes app disk activity to ZFS kernel processes

[Rudd-O]

run iotop

run a command that generates IO activity like find

notice how iotop shows ZFS kernel processes rather than find itself.

[behlendorf]

At least for writes this is what I'd expect. The user space process basically just copies its data quickly in to the ARC and then the kernel threads are responsible for moving that dirty data to disk. Since those kernel threads are the ones performing the actual IO the activity get's attributed to them. For reads the story is a little bit different since it's a synchronous operation either from cache or disk.

[Rudd-O]

But then iotop is useless to monitor writes -- to the extent that I know other filesystems do it, they work appropriately. Also, the workload I tested with was a purely read workload, and it still showed READS coming from ZFS processes...

[behlendorf]

You would see the same effect for reads assuming they aren't cached in the ARC since the actual IO get's delegated to the zfs thread pool. That said, I'll leave this as an open issue to see if we can't find some clever way to reattribute the I/O to a different process.

[Rudd-O]

For the record ext4 gets it right, even though it also has kernel threads (ext4-dio-write and the like). So they must be preserving the PID and associating it with the inflight requests.

[devsk]

AFAIK, iotop only works right if CONFIG_TASK_IO_ACCOUNTING is set.

Apart from that, the dirty IO is written to disk by the process or the background flusher thread based on dirty_* parameters. If you make dirty_background_bytes/ratio smaller than dirty_bytes/ratio, I think the IO will be done by background flusher thread ahead of the process and you will see them in the iotop instead of the process. I am not sure if the IOs in this case are also tagged and tracked with task ID if CONFIG_TASK_IO_ACCOUNTING is set.

Does ZFS have parameters which put the responsibility of the write-out on the process itself depending on how much dirty data the process is generating?

[behlendorf]

This was addressed by commit e3dc14b which was part of 0.6.3.