Analysis for fsspec/gcsfs#1048 / #1049 / #1051. Everything below was verified by reading installed sources — zarr 3.1.5, gcsfs 2026.8.0, fsspec 2026.7.0 / 2026.2.1.dev0, pyarrow 23.0.1, dask 2024.11.2 — not from memory. Written with Claude; the throughput question in the last section is explicitly not measured.
TL;DR. #1051 is a correct fix for the reported regression, and below 10 MiB it is indistinguishable from #1049. The premise that cat_file serves "small objects or metadata" holds for metadata but not for the data path: zarr's only read path is _cat_file, so cat_file call size equals the store's chunk or shard size — a value best practice puts at 10 MB–1 GB and rising. Readers that stream through fs.open() keep concurrency 4; the reader that cannot use fs.open() at all is the one pinned to 1.