Merge pull request #3 from stp/drop-known-damage-note

Drop the known-data-damage section from the README

Author: TrevorHansen

README.md

@@ -119,25 +119,6 @@ that has since moved on.
 The website updates when this repo's Pages build finishes. Nothing in `stp/stp`
 has to change.
 
-## Known data damage
-
-**`outputs/full-001.jsonl.gz` holds 154,519 of that campaign's 160,610 runs.**
-A reboot interrupted the campaign at run 63,533; the output log was being
-appended to as a gzip stream, and the kill left an unterminated member with the
-resumed run's records appended after it. Walking the members recovers all but
-about 6,000 records — the ones still in the compressor's buffer when the
-machine went down. The published file has been repaired into a single clean
-member, so `zcat` reads it through.
-
-The results themselves are unaffected: they were committed to the database as
-each run finished, and the campaign resumed and completed. Only the retained
-stdout of those ~6,000 runs is gone, which costs the ability to re-triage
-them without re-running.
-
-Both faults behind that are fixed in `scripts/`: the log is repaired before
-anything appends to it, it is flushed on the same boundary as the database
-commit, and the per-run key no longer restarts at zero when a campaign resumes.
-
 ## Licences
 
 What is written here — the harness, the exported results, this documentation —

index.html

@@ -71,9 +71,8 @@ <h2>Files</h2>
 <h2>Repository</h2>
 <p><a href="https://github.com/stp/benchmarks-data">github.com/stp/benchmarks-data</a>
 holds all of this plus <code>scripts/</code>, the harness that runs a campaign
-and publishes it. Its README covers how a campaign is reproduced, what is
-excluded from publication and why, and the one place the data is known to be
-incomplete.</p>
+and publishes it. Its README covers how a campaign is reproduced, and what is
+excluded from publication and why.</p>
 
 </body>
 </html>

scripts/README.md

@@ -218,8 +218,7 @@ before appending to it, so the damage cannot compound; the repair is also what
 
 The published log is keyed by benchmark path, not by the DB's `output_offset`.
 That counter used to restart at zero in each process, so a resumed campaign
-numbered two different records `0` — see the README's note on `full-001`, which
-was recorded that way.
+numbered two different records `0`; `full-001` was recorded that way.
 
 ## Resuming