/proc/<pid>/io display the IO accounting fields, which are IO statistics for each running process.

dd if=/dev/zero of=/tmp/test.dat &
[1] 3828
 
 
cat /proc/3828/io
 
rchar: 323934931
wchar: 323929600
syscr: 632687
syscw: 632675
read_bytes: 0
write_bytes: 323932160
cancelled_write_bytes: 0

where:

• rchar is count of chars read. The number of bytes which this task has caused to be read from storage. This is simply the sum of bytes which this process passed to read() and pread(). It includes things like tty IO and it is unaffected by whether or not actual physical disk IO was required (the read might have been satisfied from pagecache)
• wchar is count of chars written. The number of bytes which this task has caused, or shall cause to be written to disk. Similar caveats apply here as with rchar.
• syscr is a count of read syscalls. Attempt to count the number of read I/O operations, i.e. syscalls like read() and pread().
• syscw is a count of writen syscalls. Attempt to count the number of write I/O operations, i.e. syscalls like write() and pwrite().
• read_bytes is count of bytes read. Attempt to count the number of bytes which this process really did cause to be fetched from the storage layer. Done at the submit_bio() level, so it is accurate for block-backed filesystems. TODO: Add status regarding NFS and CIFS at a later time.
• write_bytes is count of bytes written. Attempt to count the number of bytes which this process caused to be sent to the storage layer. This is done at page-dirtying time.
• cancelled_write_bytes The big inaccuracy here is truncate. If a process writes 1MB to a file and then deletes the file, it will in fact perform no writeout. But it will have been accounted as having caused 1MB of write. In other words: The number of bytes which this process caused to not happen, by truncating pagecache. A task can cause “negative” IO too. If this task truncates some dirty pagecache, some IO which another task has been accounted for (in its write_bytes) will not be happening. We _could_ just subtract that from the truncating task's write_bytes, but there is information loss in doing that.