docs: fewer round trips for remote files in the browser, counted

CHANGELOG (Unreleased): the v1 B-tree lookup, `Storage::hint`, the walks that go on past a missing node, and the counts before and after on an h5py file like the reviewer's (3000 datasets, 198 MB, earliest and latest libver, 1 MiB and 64 KiB blocks), the corpus read lazily at 512 B and 64 KiB blocks, and the Node/Chromium suite. known-issues (browser limits, round trips): the new counts, why the passes cannot go lower (the chain of addresses), why merging nearby requests does not help such a file, and that a second listing refetches at 1 MiB blocks when the file's metadata blocks exceed `cacheSize`. range-reads.md M4 status and the viewer README follow. Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
2026-09-27 22:48:47 -05:00
parent 761bdbf24f
commit 2e5b059530
4 changed files with 92 additions and 6 deletions
@@ -70,8 +70,10 @@ are fetched (in parallel, adjacent blocks in one request), and the pass is
 run again, until one completes (`docs/design/range-reads.md`, M4). Opening
 costs one request (the first block, which also gives the file's size);
 listing a group whose metadata is in blocks already fetched costs none,
-and otherwise a round trip per level of the group's index plus one for
-its children's headers, all fetched together;
+and otherwise about a round trip per level of the group's index plus one
+for its children's headers, all fetched together (the reader fetches
+what it knows it reads next along with what a pass missed); opening one
+object looks its name up in the group's index, not the whole group;
 reading a chunked dataset costs a round trip for its chunk index (a few
 for a deep one) and one batch of requests for its chunks. Every answer is
 checked — a `206` with exactly the bytes asked for, from the same file