[PR #58] [MERGED] feat(daemon): keep bulky regenerable state off the host root #60

New issue

Closed

opened 2026-10-15 12:51:42 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 12:51:42 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/games-on-whales/LXC2Docker/pull/58
Author: @JBailes
Created: 6/5/2026
Status: ✅ Merged
Merged: 6/5/2026
Merged by: @JBailes

Base: main ← Head: feat/pve-cache-off-root

📝 Commits (1)

562e3c4 feat(daemon): keep bulky regenerable state off the host root

📊 Changes

10 files changed (+97 additions, -7 deletions)

View changed files

📝 cmd/docker-lxc-daemon/main.go (+4 -0)
📝 internal/api/buildkit_cache.go (+1 -1)
📝 internal/api/buildkit_exec.go (+1 -1)
📝 internal/api/containers.go (+11 -1)
📝 internal/api/containers_extra.go (+1 -1)
➕ internal/lxc/cachedir_test.go (+27 -0)
📝 internal/lxc/diskspace.go (+1 -0)
📝 internal/lxc/manager.go (+48 -1)
📝 internal/lxc/pve_tarball.go (+2 -2)
📝 readme.md (+1 -0)

📄 Description

Why

The daemon's large, regenerable data — PVE image rootfs tarballs, OCI unpacks, named-volume backing, and the buildkit cache — all lived under the state dir (/var/lib/docker-lxc-daemon) on the host root. On a node with a small root pool that's a slow leak toward a full root (image tarballs alone were ~3 G on the affected host), which destabilizes everything. Sibling to the Wolf-game-library-on-root problem, but for the daemon's own state.

What

A single, configurable cache location for bulky data, separate from the small JSON metadata, via --cache-path:

explicit --cache-path wins;
empty + a directory-capable PVE storage (a ZFS pool, mounted at /<pool>) → auto-defaults the cache onto that pool, off root;
empty on block storage (lvmthin/lvm, no POSIX mountpoint) → stays on the state dir and logs a recommendation to set --cache-path.

Manager.CacheDir() / SetCacheDir() resolve and own the path. Tarball, OCI, volume-root, and buildkit-cache call sites derive from it (the API via a nil-safe h.cacheDir() that falls back to the store root for tests). The disk-pressure watcher (PR #57) also watches the cache filesystem.

Backward compatible: image and volume records store absolute paths, so existing tarballs/volumes keep resolving; only new writes land in the new location.

Tests

Unit test covers resolveCacheDir across explicit / zfs-auto / lvmthin-fallback / legacy. make test (unit + integration) green.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/games-on-whales/LXC2Docker/pull/58 **Author:** [@JBailes](https://github.com/JBailes) **Created:** 6/5/2026 **Status:** ✅ Merged **Merged:** 6/5/2026 **Merged by:** [@JBailes](https://github.com/JBailes) **Base:** `main` ← **Head:** `feat/pve-cache-off-root` --- ### 📝 Commits (1) - [`562e3c4`](https://github.com/games-on-whales/LXC2Docker/commit/562e3c412766323f9b8c986bc81ff72a6d171d7a) feat(daemon): keep bulky regenerable state off the host root ### 📊 Changes **10 files changed** (+97 additions, -7 deletions) <details> <summary>View changed files</summary> 📝 `cmd/docker-lxc-daemon/main.go` (+4 -0) 📝 `internal/api/buildkit_cache.go` (+1 -1) 📝 `internal/api/buildkit_exec.go` (+1 -1) 📝 `internal/api/containers.go` (+11 -1) 📝 `internal/api/containers_extra.go` (+1 -1) ➕ `internal/lxc/cachedir_test.go` (+27 -0) 📝 `internal/lxc/diskspace.go` (+1 -0) 📝 `internal/lxc/manager.go` (+48 -1) 📝 `internal/lxc/pve_tarball.go` (+2 -2) 📝 `readme.md` (+1 -0) </details> ### 📄 Description ## Why The daemon's large, regenerable data — PVE image rootfs tarballs, OCI unpacks, named-volume backing, and the buildkit cache — all lived under the state dir (`/var/lib/docker-lxc-daemon`) on the **host root**. On a node with a small root pool that's a slow leak toward a full root (image tarballs alone were ~3 G on the affected host), which destabilizes everything. Sibling to the Wolf-game-library-on-root problem, but for the daemon's own state. ## What A single, configurable **cache location** for bulky data, separate from the small JSON metadata, via `--cache-path`: - explicit `--cache-path` wins; - empty **+ a directory-capable PVE storage** (a ZFS pool, mounted at `/<pool>`) → auto-defaults the cache onto that pool, off root; - empty on **block storage** (lvmthin/lvm, no POSIX mountpoint) → stays on the state dir and **logs a recommendation** to set `--cache-path`. `Manager.CacheDir()` / `SetCacheDir()` resolve and own the path. Tarball, OCI, volume-root, and buildkit-cache call sites derive from it (the API via a nil-safe `h.cacheDir()` that falls back to the store root for tests). The disk-pressure watcher (PR #57) also watches the cache filesystem. **Backward compatible:** image and volume records store absolute paths, so existing tarballs/volumes keep resolving; only new writes land in the new location. ## Tests Unit test covers `resolveCacheDir` across explicit / zfs-auto / lvmthin-fallback / legacy. `make test` (unit + integration) green. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-15 12:51:42 +00:00

closed this issue
added the
pull-request
label

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

games-on-whales/LXC2Docker#60

No description provided.

Rows
Columns