Disk I/O profiling with eBPF
Comments on “Disk I/O profiling with eBPF”
Claim-checked. Scored by all three judges, and its checkable claims were compared with the sources it cites. How far stories are checked
Coroot's node-agent now includes an eBPF disk I/O profiler, on by default, that attributes block-request time and bytes read or written to application stacks. It hooks submit_bio and bio_endio rather than scheduler off-CPU events, and samples at most one request per millisecond per CPU, weighted by the requests skipped. The author's tests on one 12-core machine (pgbench, fio) show up to 1.6% lower throughput, and the figures are self-reported. A retention-job case on a Percona cluster traced heavy reads to cold-page deletes.
Why it ranked
No. 20 of 111 with a score of 0.62. The panel rated it highest on new information (0.93) and technical depth (0.92), lowest on audience breadth (0.55). Placed No. 20, No. 46 by score alone: the placement terms moved other stories past it.
- AI judgeJudge 2claude-haiku-5-5
- Detailed, technically deep engineering write-up of eBPF block-layer I/O profiling with reproducible design and overhead data, though partly a product promotion for the vendor's agent.
- AI judgeJudge 3gpt-5.6-luna
- A technically detailed engineering write-up explains eBPF block-layer profiling, async I/O attribution, sampling, overhead, and a concrete database incident. It is highly actionable, though vendor framing and product calls-to-action make it mildly promotional.
Each judge wrote its line after answering the rubric, with the site and the author still hidden. Every answer behind this is in the table under Score.
Score
0.62total under rubric v2.3
- Significance0.56
- Reader interest0.76
- Audience breadth0.55
- Practical relevance0.73
- Substantiated0.79
- Technical depth0.92
- New information0.93
- Counts against: Promotional0.27
- Counts against: Overclaim0.25
Each judge’s answer per question (0–1), their mean and spread, and what the question adds to the score (weight × mean).
| Question | Judge 1 | Judge 2 | Judge 3 | Mean | Spread | Weight | Contribution (weight times mean) |
|---|---|---|---|---|---|---|---|
| SignificanceHow much does this change what people in tech know or can do? | 0.61 | 0.40 | 0.68 | 0.56 | 0.28 | +0.24 | +0.135 |
| Reader interestWould a well-informed senior engineer or tech founder want to read this today, and likely pass it on? | 0.73 | 0.70 | 0.86 | 0.76 | 0.16 | +0.26 | +0.198 |
| Audience breadthHow many people who build technology does it concern? | 0.57 | 0.45 | 0.62 | 0.55 | 0.17 | +0.13 | +0.071 |
| Practical relevanceHow useful is it to someone who builds software or tech products? | 0.81 | 0.60 | 0.79 | 0.73 | 0.21 | +0.22 | +0.162 |
| SubstantiatedHow well is it backed? Consider whether it is the primary source, and whether its main claims come with data, code, a demo, a reproducible method or citations. | 0.96 | 0.60 | 0.82 | 0.79 | 0.36 | +0.05 | +0.040 |
| Technical depthHow technically substantive is it? | 0.99 | 0.85 | 0.91 | 0.92 | 0.14 | +0.05 | +0.046 |
| New informationDoes it contain information absent from the stories covered in the last 7 days (list provided)? | 0.90 | 0.90 | 0.98 | 0.93 | 0.08 | +0.05 | +0.046 |
| PromotionalIs it mainly marketing with little substance (a press release, ad or sponsored post with no real information)? A launch post that carries real news is not promotional. | 0.08 | 0.45 | 0.28 | 0.27 | 0.37 | −0.19 | −0.051 |
| OverclaimDo the headline or conclusions claim more than the body supports? | 0.28 | 0.30 | 0.18 | 0.25 | 0.12 | −0.11 | −0.028 |
| Sum of contributions | +0.619 | ||||||
| Claim-check penalty | 0.000 | ||||||
| Total, as published | 0.619 | ||||||
Spread is the highest minus the lowest judge answer. marks a spread above 0.40: the judges disagree, and the story is marked contested.
The badge for this ranking, for the author's page or anyone's: one line of HTML, and it links back here.
<a href="https://rubric.hrih.si/editions/2026-10-31/20/"><img src="https://rubric.hrih.si/badge/2026-10-31/20.svg" alt="Ranked #20 on Rubric, 31 Oct 2026" width="245" height="28"></a>Claim check
Claim check: 1 matches source · 5 no source given · 2 couldn’t check. Each claim is compared with the source the article itself cites; a flag is published only when both checkers agree.
No source givenNumber
Coroot's I/O profiling adds about 100ns per request at submission and 70ns at completion, which is 1.6% of one core at 700,000 IOPS, per bpf_stats.
The article gives no link or citation for it.
The article says “bpf_stats reports about 100ns per request at submission and 70ns at completion, which is 1.6% of one core at 700,000 IOPS”
The source says No source to compare with.
No source givenBenchmark result
In the author's overhead tests on a 12-core machine, pgbench select-only throughput dropped 0 to 1.6% from a 74,000 TPS baseline with I/O profiling, while pgbench TPC-B and fio io_uring 4k random reads showed changes within run-to-run noise.
The article gives no link or citation for it.
The article says “pgbench select-only 74,000 TPS 0 to 1.6% lower”
The source says No source to compare with.
No source givenCausal conclusion
The block_bio_complete tracepoint only fires for bio-based devices like md and dm, and for blk-mq devices (NVMe, virtio, SCSI) completion is traced at the request level.
The article gives no link or citation for it.
The article says “block_bio_complete only fires for bio-based devices like md and dm. For every blk-mq device, which is every NVMe, virtio and SCSI disk today”
The source says No source to compare with.
Matches sourceNumber
Storing profiles in ClickHouse is cheap because stacks are stored once and per-minute rows reference them by hash, and the columnar format compresses those rows by an order of magnitude.
The cited source says the same thing.
The article says “the columnar format compresses those rows by an order of magnitude”
The source says “profiling_samples │ 6.19 GiB │ 75.05 GiB │ 12.1 │ 923695809”
Source cited by the article: coroot.com/blog/storing-continuous-profiling-data-in-clickhouse
Couldn’t checkNumber
During the retention CronJob on rca-lab, reads rose from near zero to 7MB/s, writes from 2MB/s to 30MB/s, and I/O load from 0.5 to 5 seconds per second.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “Reads on all three nodes go from near zero to 7MB/s, writes from 2MB/s to 30MB/s, and the I/O load from 0.5 to 5 seconds per second”
The source says No passage could be compared.
Source cited by the article: github.com/coroot/rca-lab
Couldn’t checkNumber
During the retention job, query latency on the writer doubled from 4ms to 9ms and order-service became about 20% slower.
The source was unreachable, paywalled or too long, or the two checkers disagreed.
The article says “Query latency on the writer doubles, from 4ms to 9ms, order-service gets about 20% slower”
The source says No passage could be compared.
Source cited by the article: github.com/coroot/rca-lab
No source givenCausal conclusion
The retention job's DELETE reads are heavy because the oldest rows' pages were long evicted from the buffer pool, so each must be read back from disk, and the writes come from the page cleaner and doublewrite buffer flushing dirtied pages.
The article gives no link or citation for it.
The article says “The rows being deleted are the oldest in the table, so their pages are the coldest, long evicted from the buffer pool”
The source says No source to compare with.
No source givenNumber
In the RCA investigation, the replication apply path on the other nodes went from 6% to 56% of all disk reads.
The article gives no link or citation for it.
The article says “the replication apply path on the other nodes went from 6% to 56% of all disk reads”
The source says No source to compare with.
Also covered by
No other coverage was clustered with this story.
Elsewhere
Elsewhere: HN 3 pts, front page
Recorded for context only, checked 31 Oct 2026, 05:46 UTC. It played no part in the ranking.