Why don't reads from /dev/zero count as IO_RBYTES?

Question

I am emptying out a hard drive on some Linux 4.x OS using this command:

sudo sh -c 'pv -pterb /dev/zero > /dev/sda'

And I opened another tty and started sudo htop and noticed this:

  PID USER      PRI  NI CPU%   RES   SHR   IO_RBYTES   IO_WBYTES S   TIME+  Command
 4598 root       20   0 15.5  1820  1596        4096    17223823 D  1:14.11 pv -pterb /dev/zero

The value for IO_WBYTES seems quite normal, but IO_RBYTES remains at 4 KiB and never changes.

I ran a few other programs, for example

dd if=/dev/zero of=/dev/zero
cat /dev/zero > /dev/zero

and was surprised to see none of them generates a lot of IO_RBYTES or IO_WBYTES.

I think this is not specific to any program, but why don't reads from /dev/zero and writes to /dev/{zero,null} count as I/O bytes?

@marcelm I think any input/output should count as I/O, including file R/W, network I/O and many more. — iBug, Feb 21 '19 at 00:56
but those operations perform I/O to _hardware_ (disk, and the network card, respectively), and have to travel over some I/O bus (such as PCI-express), all of which can be a significant bottleneck. Writes to, say, `/dev/null` don't end up interfacing wich such hardware and don't clog I/O buses. Taken to the extreme; are reads/writes to/from memory also I/O? Of course, there is no hard delineation for these things, and it all depends on which perspective you take in these things, and how useful that perspective ends up being to you. — marcelm, Feb 21 '19 at 11:39
Note, my first comment was intended to provoke you (and others) to think about those perspectives, and find out why you're taking your perspective. I don't mean to insinuate you're wrong; I don't even think the situation is that black and white. But personally, I would be a lot more interested in I/O statistics to actual hardware (which may very well be a bottleneck) than to `/dev/{null,zero}` (which usually isn't a bottleneck). That's just my perspective though :) — marcelm, Feb 21 '19 at 11:44
@marcelm But I was initially thinking that any `read(2)` and `write(2)` counts as I/O, which is very reasonable in its own sense. — iBug, Feb 21 '19 at 11:51

Stephen Kitt · Accepted Answer · 2019-02-20T11:06:27.330

They do count as I/O, but not of the type measured by the fields you’re looking at.

In htop, IO_RBYTES and IO_WBYTES show the read_bytes and write_bytes fields from /proc/<pid>/io, and those fields measure bytes which go through the block layer. /dev/zero doesn’t involve the block layer, so reads from it don’t show up there.

To see I/O from /dev/zero, you need to look at the rchar and wchar fields in /proc/<pid>/io, which show up in htop as RCHAR and WCHAR:

rchar: characters 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(2) and similar system calls. It includes things such as terminal I/O and is unaffected by whether or not actual physical disk I/O was required (the read might have been satisfied from pagecache).

wchar: characters 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.

See man 5 proc and man 1 htop for details.

So it's `rchar` and `wchar` that count bytes from calls to `read(2)` and `write(2)`, right? — iBug, Feb 20 '19 at 11:00
Talk about misleading phrasing on the description of _rchar_. Everything passed through `read()` most definitely isn't "read from _storage_"! — ilkkachu, Feb 20 '19 at 11:32
@ilkkachu by `storage` they mean "any conceivable bus line", regardless of whether the storage in question is physical or virtual or mmap'd or a virtual socket or in L1 cache -- it's just anything outside of that program's mapped memory including shared — cat, Feb 20 '19 at 23:53

Why don't reads from /dev/zero count as IO_RBYTES?

1 Answers1