proc_pid_io(5)

💖 proc_pid_io — I/O statistics 💖

okay bestie so you found the proc_pid_io(5) page in the File Formats Manual section, and honestly? it's a little gem. it's the manual for /proc/pid/io, the file that spills all the tea about a process's I/O. let's get into it 🫶

---

✨ NAME ✨

/proc/pid/io — I/O statistics. that's it, that's the whole vibe 💅

---

🌸 DESCRIPTION 🌸

so /proc/pid/io has been sitting there since Linux 2.6.20 (yes, ancient, iconic, a legend). it holds the I/O statistics for a process and its waited-for children. like, the whole family tree of I/O.

here's what it looks like when you peek at it, fr fr:

# cat /proc/3828/io
rchar: 323934931
wchar: 323929600
syscr: 632687
syscw: 632675
read_bytes: 0
write_bytes: 323932160
cancelled_write_bytes: 0

and now the field-by-field breakdown, because you know I'm gonna explain every single one 👑

🎀 the fields 🎀

• rchar: characters read — the number of bytes returned by successful read(2) and similar system calls. it's giving "how much did this thing actually pull in".
• wchar: characters written — the number of bytes returned by successful write(2) and similar system calls. the outgoing side of the story ✨
• syscr: read syscalls — the number of "file read" system calls. that means the whole read(2) family, plus sendfile(2), copy_file_range(2), and the ioctl(2) BTRFS_IOC_ENCODED_READ[_32] one — and that includes when the kernel invokes them as part of other syscalls. sneaky kernel behavior, we love to see it documented.
• syscw: write syscalls — the number of "file write" system calls. same deal: the write(2) family, sendfile(2), copy_file_range(2), and ioctl(2) BTRFS_IOC_ENCODED_WRITE[_32] — including when the kernel calls them as part of other syscalls.
• read_bytes: bytes read — the number of bytes really fetched from the storage layer. and it's accurate for block-backed filesystems, periodt. 🔥
• write_bytes: bytes written — the number of bytes really sent to the storage layer.
• cancelled_write_bytes: — okay bestie this one needs a second. the stats above do not account for truncation. so picture it: a process writes 1 MB to a regular file and then deletes it. that 1 MB never actually gets written, but it was still counted as a 1 MB write 🙈. this field is the number of bytes that got "saved" from I/O writeback. and lowkey it can go negative — like, actually negative I/O — if caches that were dirtied by another process get truncated. also important: cancelled_write_bytes applies to I/O already accounted-for in write_bytes.

🔐 who's allowed in 🔐

permission to access this file is governed by ptrace(2) access mode PTRACE_MODE_READ_FSCREDS. so it's not a free-for-all, bestie.

---

💀 CAVEATS 💀

these counters are not atomic. on systems where 64-bit integer operations may tear, a counter could get updated at the exact same moment as a read, and you'd end up with an incorrect intermediate value. so if a number looks cursed, it might genuinely be cursed. not a vibe, but forewarned is forearmed 💜

---

🦋 SEE ALSO 🦋

• getrusage(2)
• proc(5)

---

and that's the whole page, bestie!! 🎀 this was Linux man-pages 6.20, dated 2026-02-08, and you just read proc_pid_io(5) like a true main character. go check your own /proc/pid/io and slay 💅✨🫶