[TianDi101]

Two fixes for put failures that look like errors but aren't, both found in the e2e of #762/#763/#774/#775/#776 (DRAM 300 GB + SSD 600 GB).

1. Sample PageBackend's allocation-failure WARN

PageBackend::AllocateLocked logged one WARN per failed key, under the backend's exclusive lock. When a DRAM tier fills, every put and every promotion fails there.

Seen in: test/umbp-e2e-v4, promote_trigger: on_read.

• The first read burst kept DRAM at 100% for 2.5 minutes.
• That window logged 640,868 Allocate reason=NO_SPACE lines, while the tier needed that same lock to serve reads, commit and evict.
• feat(umbp): SSD demote/promote skip staging; promoting reads land in DRAM; 4 GiB staging preset #776's inline promotion multiplies this line (v2c2, without it, logged 17k), but the line itself is in main.

Change: log the first 16 failures and then every 10,000th, with the running count. The counter is guarded by the lock the function already holds.

2. A put whose key is already being stored is not a failure

When two writers put the same key at once, PeerPool refuses the second because the first holds the reservation. Local puts reported that as a failure, although the first writer stores the same bytes.

Seen in: test/umbp-e2e-v5, during a read burst. Four DP ranks offloaded the same shared-prefix pages together, and sglang's linker logged UMBP offload failed: ... success=1/31.

• The linker also stops the rest of that offload batch on any false, so a harmless race cost other pages their offload.
• Nothing failed in UMBP: every allocation committed, with 0 aborts and 0 failed transfers.
• It predates this chain: 10 of 33 earlier runs show it, 8–28 times per 2 h run.

Change: PeerPool flags that refusal as in_flight. Its outcome stays kFailed, so other callers (remote writers in master mode) are unchanged and nothing reads uncommitted bytes. The three local put paths treat in_flight like "already exists". No sglang change: it only logs when UMBP returns false.

Testing

• Part 1: test_page_backend, umbp_peer_pool, test_ssd_backend, umbp_medium_selection and umbp_pool_client_batch_put pass. No test asserts on the WARN line.
• Part 2: new assertions in PeerPool.ReservesDuplicateKeysUntilCommitOrAbort, and BatchPutWarnTest.KeyAlreadyBeingStoredIsNotAFailure (same key twice in one batch). The unit suite run is pending; a free node opens when the current e2e ends.

🤖 Generated with Claude Code