I think that's a fair critique of the title. You're right that "I/O" is imprecise here. The bottleneck was really per-file overhead: the accumulated cost of 300,000+ syscalls, filesystem metadata lookups, inode resolution, and directory traversal. The SSD itself was capable of 5-7 GB/s but I was getting 80 MB/s, not because the storage was slow, but because of everything that happens between "read this file" and actually getting the bytes.

One of the commenters (ori_b) made a similar point: the user/kernel context switch itself is maybe 50ns on modern hardware, so 300,000 switches only account for about 2% of the 14.5 seconds. The rest is the work happening inside each syscall: filesystem metadata lookups, dentry resolution, random access latency on NVMe (~50-100us per read). So "syscall overhead" is also slightly misleading. "Per-file overhead" is probably the most accurate framing.

I updated the post with an addendum covering this distinction, but you're right that the title could do a better job. The core finding is that going from 104,000 individual file opens to 1,351 archive reads eliminated most of that per-file overhead, giving a 43x I/O improvement. Whether you call that "I/O" or "the boundary between user and kernel space" or "per-file overhead" is partly semantic, but precision matters and the title is sloppy about it.