Apple Silicon Cloud-Mac-Runner: Speicher, Inodes, Derived Data & Docker

Kernpunkte

Beobachten Sie parallel df -h und df -ih: Inode-Sättigung wirkt wie „geheimnisvolle“ Schreibfehler, obwohl noch Gigabyte frei sind.
Verteilen Sie Aufbewahrung: heiße Build-Caches (Stunden), lauwarme Xcode-Artefakte (Tage), kalte Logs (Wochen) — mit klarem Eigentümer je Verzeichnisbaum.
Docker-Graphen (oder Äquivalente) erzeugen viele kleine Dateien im Overlay; koppeln Sie Image-Pruning mit Inode-Checks auf dem Host, nicht nur mit Volume-Größen.
Dimensionieren Sie Runner nach Tarif-SSD abzüglich macOS, Apps und Puffer; streben Sie nach dem pessimistischen Wochenwachstum etwa 15 bis 20 % freien Speicher an.

Rechenzentrum mit Serverracks, metaphorisch für Kapazitätsplanung auf Cloud-Mac-Runnern — Illustratives Foto; operative Wahrheit steckt in `df`, Log-Rotation und Ihrer CI-Cache-Landkarte.

1. Wo Bytes und Inodes sich verstecken

Derived Data und SourcePackages dominieren interaktive und CI-getriebene Xcode-Last: inkrementelle Builds sind schnell, weil Indizes liegen bleiben. Auf geteilten Runnern ohne ephemeral Root pro Job kann ein Branch-Wechsel gigabytegroße Arbeitskopien hinterlassen. Swift Package Manager- und CocoaPods-Caches legen eine Schicht oben drauf; Pod-Bäume sind berüchtigt für extreme Dateizahlen bei noch moderater Gesamtgröße.

Container duplizieren Layer und Metadaten; Bind-Mounts, die node_modules oder Testdaten vom Host ziehen, vervielfachen den Inode-Druck auf dem darunterliegenden APFS-Volume. Unified Logging (log show, DiagnosticReports, von launchd-Jobs archivierte Stdout-Ausgaben) wächst unauffällig, solange keine Rotation greift. Behandeln Sie jede Kategorie wie eine Zeile in einer einfachen Tabelle: erwarteter Spitzenwert in GB, Inode-Anteil, maximal akzeptables Alter.

Container-Layer und BuildKit-Cache schneiden dieses Thema direkt — ordnen Sie dieses Modell dem Leitfaden Produktions-Docker auf Apple-Silicon-Cloud-Mac: arm64/amd64-Images, Bind-Mounts & Build-Cache — Fehlerbehebungs-Handbuch (mit Tarif-Grenzen) zu, um Bind-Mounts, lokalen Graphen und gemeinsames SSD-Budget mit Xcode zu verzahnen.

2. Quotenartige Alarme vor der „Festplatte voll“-Seite

Alarmieren Sie belegten Speicheranteil und Inode-Anteil getrennt. APFS vermeidet klassische Fragmentationsklippen oft, aber Dienste werden trotzdem nahe am Rand instabil: Snapshots, lokale Time-Machine-Caches und temporäre CI-Verzeichnisse teilen sich die letzte Marge. Ergänzen Sie eine Warnung auf der Wachstumsableitung: übersteigt das rollierende 7-Tage-Wachstum Ihre Tarifreserve, früh warnen.

Nutzen Sie denselben Kanal wie bei Build-Fehlschlägen; Festplatten-Störungen wirken wie flaky Tests. Nennen Sie welches Dateisystem der Job berührt — Container-Graph gegen Host-/Users —, um im Incident nicht die falsche Schicht zu purgen.

# Schneller Host-Snapshot (für Health Checks)
df -h /
df -ih /
du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null
docker system df 2>/dev/null || true

3. Gestufte Bereinigung

Stufe 0 — stündlich sicher: CI-Logs mit bekannter Größe kappen, Workspaces gescheiterter Jobs älter als N Stunden entfernen, Container-Build-Cache-Einträge mit explizitem TTL verdrängen.

Stufe 1 — täglich: hängende Docker-Images und gestoppte Container löschen; Derived-Data-Ordner pro PR nach geschlossenen Merges entfernen; Unified Logging gemäß Aufbewahrungsrichtlinie rotieren.

Stufe 2 — wöchentlich: kalte Caches nach Lockfiles neu aufbauen, wenn Geheimnisse gesichert sind; SPM-Caches kompaktieren, wenn Integritätsprüfungen grün sind; Bind-Mounts auf versehentliche Kopien von .git oder DerivedData auf dem Host prüfen.

Stufe 3 — Notfallglas: alte globale Xcode-Daten und globale Caches nur im Wartungsfenster mit nachvollziehbaren Rebuilds entfernen. Dokumentieren Sie, was gelöscht wurde — Auditoren fragen danach.

Für eingehende Ausführungsketten und Aufbewahrung von Belegen lässt sich die Policy mit OpenClaw-Rückrufe mit Cloud-Mac-Runnern verketten: Low-Trust-Eingangsvalidierung, Ausführungsisolation, idempotente Retries – und wie man Observability- und Audit-Felder entwirft abstimmen, damit Compliance-Nachweise nicht „zur Platzfreigabe“ verschwinden.

4. Tarifgrenzen und SSD-Puffer

Öffentliche kvmboot-Stufen liegen bei 16 GB einheitlicher Arbeitsspeicher + 256 GB SSD und 24 GB + 512 GB (siehe Tarife und Datenblätter). Budgetieren Sie zuerst macOS, Xcode, Docker Desktop oder Äquivalent, Monitoring-Agenten und zwei Wochen Logs; den Rest teilen Sie CI-Caches und ephemeral Stores pro Runner zu. Modellieren Sie bei parallelen Jobs in Release-Trains das pessimistische Überlappungsszenario — zwei große iOS-Archive plus ein containerisiertes Backend-Build können RAM und transienten Speicher spiken, bevor die Bereinigung läuft.

Halten Sie nach diesem Szenario etwa 15 bis 20 % frei. Unter ~10 % folgen kryptische Timeouts in Compilern, Test-Runnern und Paketmanagern — teuer zu debuggen unter Incident-Druck.

5. Symptom — Ursache — Maßnahme

Symptom	Wahrscheinliche Ursache	Bevorzugte Maßnahme
„No space left on device“, aber `df -h` zeigt freie GB	Inode-Sättigung oder Quota auf verschachteltem Volume	`df -ih` ausführen; Bäume mit extrem vielen kleinen Dateien leeren (Pods, Overlays, alte Logs)
CI wird nach mehreren grünen Builds langsamer	gewachsene Caches; APFS-Metadaten-Hotspots	Derived Data zeitlich begrenzen; Docker-Builder-Cache purgen; Bind-Mounts prüfen
Speicher-Alarme nur auf einem Runner	Host-Drift: manuelle Debug-Artefakte	`du`-Summen pro Top-Level vergleichen; neu imagen oder „Concierge“-Skript erzwingen

6. Fazit

Speicher-Governance auf Cloud-Mac-Runnern ist kein einzelnes Cron-Job-Thema, sondern ein Kapazitätsmodell, das Xcode-Caches, Container, Logs und Tarif-SSD — plus Inode-Bewusstsein — verbindet. Überarbeiten Sie das Modell bei großen Xcode-Upgrades, neuen Parallel-Jobs oder zusätzlichen Docker-Sidecars; jede Änderung verschiebt sowohl die Byte- als auch die Dateizahl-Kurve.