s1d3sw1ped/steamcache2
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases 32 Wiki Activity

ops: Signal disk-tier attach pending vs ready #45

Merged
linus merged 1 commits from ops/disk-tier-attach-signal into develop 2026-09-07 12:02:10 -05:00
Conversation 0 Commits 1 Files Changed 5
+134 -4
pike commented 2026-09-07 11:58:47 -05:00
Collaborator
Copy Link
Copy Source

Why

Large disk caches can look memory-only/broken for seconds–minutes at startup while the disk tier attaches. That warm-up is intentional but opaque — operators should not need to read source to see attach pending vs ready.

What

  • disk_tier_ready gauge (0 pending / 1 ready, or 1 when no disk = N/A not waiting) in /metrics via existing WriteText
  • Info logs: attach pending at start + attached when SetSlow completes (disk-only and mixed)
  • /lancache-heartbeat header X-SteamCache-Disk-Tier: pending|ready|disabled
  • GetMetrics skips blocking disk.Size() while attach pending so /metrics stays responsive
  • README Quick check + Large Cache Initialization notes

How tested

  • go test ./steamcache/ -count=1 (PASS)
  • Focused: TestDiskOnlyDelayedAttach, TestDiskTierSignalMemoryOnly, TestDiskTierSignalMixedPendingReady
  • Review-labels grep (check-review-labels recipe) clean

Risks

  • Low: additive metrics/header/logs; attach path semantics unchanged
  • During pending, disk_cache_size in metrics may stay at last/zero until ready (by design — avoids hang)

Rollback

Revert this PR / merge revert commit.

Closes #33

## Why Large disk caches can look memory-only/broken for seconds–minutes at startup while the disk tier attaches. That warm-up is intentional but opaque — operators should not need to read source to see attach pending vs ready. ## What - `disk_tier_ready` gauge (`0` pending / `1` ready, or `1` when no disk = N/A not waiting) in `/metrics` via existing WriteText - Info logs: attach pending at start + attached when SetSlow completes (disk-only and mixed) - `/lancache-heartbeat` header `X-SteamCache-Disk-Tier: pending|ready|disabled` - `GetMetrics` skips blocking `disk.Size()` while attach pending so `/metrics` stays responsive - README Quick check + Large Cache Initialization notes ## How tested - `go test ./steamcache/ -count=1` (PASS) - Focused: `TestDiskOnlyDelayedAttach`, `TestDiskTierSignalMemoryOnly`, `TestDiskTierSignalMixedPendingReady` - Review-labels grep (check-review-labels recipe) clean ## Risks - Low: additive metrics/header/logs; attach path semantics unchanged - During pending, `disk_cache_size` in metrics may stay at last/zero until ready (by design — avoids hang) ## Rollback Revert this PR / merge revert commit. Closes #33
eva was assigned by pike 2026-09-07 11:58:47 -05:00
pike added 1 commit 2026-09-07 11:58:47 -05:00
ops: Signal disk-tier attach pending vs ready
CI / vulncheck (pull_request) Successful in 14s
Details
CI / check-and-test (pull_request) Successful in 40s
Details
12ea3ee4f6 
Large disk caches can look memory-only/broken during async DiskFS attach.
Expose disk_tier_ready in /metrics, pending/ready logs for disk-only and
mixed modes, and X-SteamCache-Disk-Tier on /lancache-heartbeat. GetMetrics
skips blocking disk.Size() while attach is pending so /metrics stays usable.

Closes #33
pike requested review from eva 2026-09-07 11:58:47 -05:00
linus merged commit 8cebc1f96c into develop 2026-09-07 12:02:10 -05:00
linus deleted branch ops/disk-tier-attach-signal 2026-09-07 12:02:10 -05:00
Sign in to join this conversation.
Reviewers
No Reviewers
eva
Labels
Clear labels
bug
Something is not working
 draft
Draft for review — do not merge without Eva review
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 wontfix
This won't be fixed
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
ash blake eva linus moss pike s1d3sw1ped
No Assignees eva
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: s1d3sw1ped/steamcache2#45
Delete Branch "ops/disk-tier-attach-signal"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?