docs: chunks of 4 GiB or more — CHANGELOG, known-issues, README

Three fixed entries (reading, writing, LZ4 over 256 MiB) and the open limits entry; the selection-read entry loses its fill-value case; the FileEditor limits gain the refused rewrites; the README tables name what is supported and what is not. Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
2026-09-28 23:44:55 -05:00
parent 7a2e61ebd1
commit 740d1124a8
4 changed files with 217 additions and 9 deletions
@@ -32,10 +32,11 @@ chunk still inflates to 4 GiB + 8 bytes.
 writes only the elements written (an unfiltered chunk larger than the chunk
 cache is written in place) and the file is sparse: tens of GiB long but a few
 blocks on disk. Unwritten elements read as whatever the file holds there:
-zeros. Do not put it on tmpfs, which is memory.
+zeros. Do not put it on tmpfs, which is memory. Its Single Chunk is
+allocated early (see `make`).

 libhdf5 holds a whole filtered chunk in memory while it writes it, so the
-`filtered` run needs about 4.5 GiB of memory (and about 3 minutes).
+`filtered` run needs about 4 GiB of memory and 100 s (tank).

 Generated 2026-09-28 with h5py 3.16.0 (libhdf5 2.0.0).
 """