Effective date: 2026-08-21
This is the canonical placement policy for shared storage used by drg-k8s and its workloads. Storage exhaustion is a shared-infrastructure failure: a single unbounded workload must never be allowed to consume capacity needed by unrelated services.
| Data class | Required location |
|---|---|
| Temporary files, caches, CI/build workspaces, build layers, downloads, extraction space, and intermediate results | Bounded local disk or RAM |
| Persistent, explicitly bounded data that genuinely needs low-latency access | /mnt/fastdata |
| Large or growing durable datasets, infrequently accessed files, libraries, and archives | /mnt/bigdata |
Neither network share is temporary storage.
Clarified 2026-09-15. For AutoCoder, “local disk” means the execution worker's local NVMe, not the control-plane root disk.
drg-k8s-worker-01.auth.home.lan (192.168.1.231), using isolated task directories under /mnt/runner-storage/autocoder-engine on its dedicated NVMe. The pod mount is /workspace/repos-rwx.drg-k8s.auth.home.lan (192.168.1.9) hosts control-plane services. Administrator conversation, inspection, lightweight source edits, and deployment coordination may remain there; AutoCoder task builds and build caches must not.drg-k8s-worker-01.auth.home.lan in selectors and operational verification.The application contract, lifecycle limits, and implementation references are maintained in AutoCoder-Engine worker execution and storage placement, governed by REQ-0091. This policy does not imply that direct administrator terminals are automatically routed or technically prevented from running arbitrary shell commands.
Live verification on 2026-09-15 found both nodes Ready and the managed worker pod autocoder-supervised-41770 on the worker host, with no managed worker pod on the control-plane node. Pod placement alone does not prove active task execution or filesystem compliance. Recheck placement without starting work:
kubectl --kubeconfig /home/ax_julian/.kube/config get pods -A \
-l app=autocoder-agent-worker \
-o custom-columns='NAME:.metadata.name,NODE:.spec.nodeName,PHASE:.status.phase'
Inspect task processes and actual mounts before claiming active execution or storage compliance.
/mnt/fastdata is scarce, fast network-attached persistent storage with about 4 TB nominal capacity. It is primarily for fast read-oriented data and explicitly bounded latency-sensitive persistent state, including VM disks, container images, and application state that has a demonstrated need for this tier.
It is not a default Kubernetes data root. It must not contain temporary data, caches, CI/build workspaces, disposable Docker or BuildKit layers, intermediate results, unbounded logs, or large/growing datasets.
Every allocation requires a documented owner, purpose, expected size, hard maximum size, growth and retention behavior, backup/recovery needs, monitoring, and a reason that /mnt/bigdata or local storage is unsuitable.
/mnt/bigdata is capacity-oriented network-attached rotational storage with read caching. It is the default shared tier for large or growing durable datasets and for files, libraries, or archives that do not require frequent low-latency access.
It is not scratch space. Temporary staging, cache data, downloads, extraction space, and other disposable intermediates must remain on bounded local disk or RAM.
All short-lived work uses local disk or RAM. This includes runner workspaces, caches, build layers, package downloads, decompression, transformations, temporary exports, and partial intermediate results.
Local temporary storage must itself be bounded, monitored, and governed by explicit cleanup or lifecycle behavior. A workload must fail closed before exhausting a node or affecting unrelated services.
Durable datasets use a compact binary format suitable for their schema and access pattern. Each dataset root contains a FORMAT.md describing:
Time-oriented datasets are divided into immutable, independently verifiable chunks. Chunk boundaries and target sizes are chosen and documented so that:
Each dataset has a machine-readable manifest or index containing, for every committed chunk, its inclusive start time, exclusive end time, schema version, record count, byte size, checksum, and relative path. Chunk names sort chronologically. Writers build and validate bulk intermediate data locally; readers accept only complete chunks referenced by the committed manifest. Publication must never expose an incomplete chunk as valid data.
The BitSurfer segmented capture implementation is a useful precedent for time-bounded segments, manifest indexing, checksums, validation, and publish-after-completion behavior. Its text encodings are not the required storage format for new large datasets; the durable payload requirement here is compact binary.
Shared-storage users must expose capacity and growth monitoring with warning and critical thresholds appropriate to the service recovery time. New or changed workloads must prove their actual mount and filesystem, maximum growth, retention, and cleanup behavior before production use. Kubernetes resource declarations alone do not bound hostPath or NFS usage.
When placement is uncertain, stop and obtain an explicit storage decision before writing data.