feat(io): adapt reader concurrency for cold files

[jfischoff]

Summary

• halve the initial CUDA pinned staging pool from 2 GiB to 1 GiB by using one buffer per reader
• conditionally grow slow, large direct reads from 16 to 32 readers after four real read completions, without probe I/O
• bypass the ramp for page-cache-hot and sub-4-GiB payloads, and fall back cleanly if additional pinned allocation fails
• expose environment overrides for disabling or tuning the ramp and cover the new policy with integrity tests

JuiceFS benchmarks

All distributed results used eight H100s and verified the complete reconstructed payload byte-for-byte on every rank.

Loading strategy	Baseline	Adaptive ramp	Time reduction
rank-0 read + broadcast, 12 GiB	20.20 s	13.23 s	34.5%
1/rank windows + all-gather, 32 GiB	22.98 s	15.66 s	31.8%
1/rank contiguous + owner broadcasts, 32 GiB	10.93 s	7.84 s	28.3%

The measured H100 NCCL roof was 331 GiB/s for broadcast and 371 GiB/s for all-gather. Collective phases took only 35-133 ms, while end-to-end loading remained 0.6-4.1 GiB/s, confirming that these runs were JuiceFS-bound rather than fabric-bound.

Single-GPU cold-load measurements improved by 25.5% on the same node and 27.1% on a fresh node. Warm page-cache loads retained the 16-reader pool and did not ramp.

Eight-GPU B200 validation was attempted through four current app pools, but every request exhausted the platform allocation window without receiving hardware. No B200 result is claimed here.

Test plan

• configured prek hooks on both changed files
• targeted reader integrity suite: 90 passed, 1 skipped
• broader prepared-environment suite: 223 passed, 4 skipped
• 8x H100 rank-0 broadcast correctness and timing
• 8x H100 1/rank all-gather correctness and timing
• 8x H100 1/rank owner-broadcast correctness and timing

[jfischoff]

@cursor review
@claude review
@codex review

[jfischoff]

@cursor review
@claude review
@codex review