26

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?

Improve this question
6
  • 5
    I'm curious, why do you think they should count as I/O?
    – marcelm
    Feb 20, 2019 at 19:58
  • 1
    @marcelm I think any input/output should count as I/O, including file R/W, network I/O and many more.
    – iBug
    Feb 21, 2019 at 0: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, 2019 at 11:39
  • 1
    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, 2019 at 11:44
  • 1
    @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, 2019 at 11:51

1 Answer 1

Reset to default
55

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.

Improve this answer
4
  • So it's rchar and wchar that count bytes from calls to read(2) and write(2), right?
    – iBug
    Feb 20, 2019 at 11:00
  • Yes, that’s right.
    – Stephen Kitt
    Feb 20, 2019 at 11:06
  • 9
    Talk about misleading phrasing on the description of rchar. Everything passed through read() most definitely isn't "read from storage"!
    – ilkkachu
    Feb 20, 2019 at 11:32
  • 2
    @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, 2019 at 23:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .