A Commit refused for disk Capacity leaves its packs in the Store, and every later write is refused Capacity

Aperta
  • Qualcosa non va?
#379 2 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@jiangkoumo ci sta già lavorando.

Dal 8/11/2026.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
43/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
linux, rust, sqlite
Ambito
backend

Direzione di ricerca

Start with 05-storage.md and the Store pack persistence and reclamation paths; the issue identifies Handles::reclaim_space and a reproducible failure during workspace.commit. Trace how packs written before a refused commit are retained and how fs.write maps a persistence Capacity error. Done means failed commits leave unreferenced packs reclaimable, a small write succeeds after the workspace shrinks, and Capacity is reported consistently.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug

Summary

When workspace.commit hits a full disk, it is refused Failed | pack persistence: Refused { status: "Capacity" }, and nothing is committed. That part is correct. But the packs it already wrote stay in store.sqlite (about 273 MB in this repro). Nothing references them, and no public or operator call removes them. After that, every write on that Store is refused Capacity: a 1 MB Commit, a write on another Branch, and a 5-byte fs.write from a new process. Deleting the large file from the Workspace does not help. The only way out is to free disk outside LayerFS or delete the Store.

Environment

  • main 5fb68ddc1 (1.0.0 plus #376–#378). Also reproduces on 792715f.
  • x86_64 Debian 13, daemon and addon built on the host with cargo +1.85.1 --offline --locked --release.
  • Store on ext4. Runtime image is Node 22 on trixie.

Reproduce

To fill the disk quickly, the Store volume is a plain local volume whose _data is bind-mounted from a 300 MiB ext4 loop disk. Any Store disk that fills up should behave the same way.

  1. project.init a 26 KB project, branch.fork("f"), then workspace.mount("f").

  2. In the Workspace: head -c 400000000 /dev/urandom > big.bin.

  3. workspace.commit(ws) → Failed: physical Store I/O: pack persistence: Refused { status: "Capacity" }, with detail.phase = "Commit Construct". list_commits("f") is empty, which is correct.

  4. operator.store.stats():

    before after the refused Commit
    logical 26,260 26,260
    canonical 30,259 272,529,372
    stored 13,066 275,696,868
    free — 0

    The disk has 268 MiB used and 2 KiB free. store.sqlite is 275,591,168 bytes.

  5. The same Workspace runs rm big.bin and writes 1 MB, then commits → Refused { status: "Capacity" }, with phase "Commit Begin".

  6. branch.fork("g") + fs.write("g", "/x.txt", "hello") → Capacity: capacity: persistence.

  7. A new process opens the Store fresh, with the old Sandbox gone. stats() is unchanged.

    • fs.write("f", "/tiny.txt", "hello") → Unknown: Service(History(Capacity("persistence")))
    • fork + mount + commit → Capacity
Repro script

The Store volume lfsb-full is a local volume whose _data is bind-mounted from a 300 MiB ext4 loop disk (truncate -s 300M img; mkfs.ext4 -m 0 img; mount -o loop img /mnt/small; mount --bind /mnt/small/store /var/lib/docker/volumes/lfsb-full/_data). The LAYERFS_* env points at that volume.

import { LayerFS } from "./sdk/js/src/index.js";
import { LayerFSOperator } from "./sdk/js/operator/index.js";
const [project, src] = process.argv.slice(2);
const lfs = new LayerFS(project); const op = new LayerFSOperator(lfs);
const T = async (k, f) => { try { const r = await f(); console.log(k, "ok", JSON.stringify(r).slice(0, 400)); return r; } catch (e) { console.log(k, "FAIL", e.code, e.message, JSON.stringify(e.detail)); return null; } };
try {
  await T("init", () => lfs.project.init(src));
  await T("fork", () => lfs.branch.fork("f"));
  const ws = await T("mount", () => lfs.workspace.mount("f"));
  await T("write-400MB", () => lfs.workspace.exec(ws, "head -c 400000000 /dev/urandom > big.bin"));
  await T("commit-full", () => lfs.workspace.commit(ws, "too big"));
  await T("stats", () => op.store.stats());
  await T("list-commits", () => lfs.branch.list_commits("f", 5, 0));
  await T("shrink", () => lfs.workspace.exec(ws, "rm big.bin && head -c 1000000 /dev/urandom > mid.bin"));
  await T("commit-small", () => lfs.workspace.commit(ws, "small"));
  await T("fs.write-other-branch", () => lfs.branch.fork("g").then(() => lfs.fs.write("g", "/x.txt", "hello", "w")));
  await T("unmount", () => lfs.workspace.unmount(ws, true));
  await T("stats-end", () => op.store.stats());
} finally { await lfs.close(); }

The reopen step is a second process: stats(), fs.write("f", "/tiny.txt", "hello"), then fork + mount + commit.

Expected

  • A Commit refused before publication should leave no persistent bytes. Its packs should be deleted on the definite failure, or reclaimed on the next open, or a documented operator call should be able to reclaim them. After the Workspace shrinks, a small Commit should succeed.
  • stats() should not count packs that nothing references.
  • fs.write should refuse Capacity here, not Unknown. Per #372, Unknown also keeps its Store call Workspace.

Notes

  • I checked issues and PRs through #378 and found no report of this. #311 and #321 cover Workspace-overlay reclamation, and they say that local overlay maintenance does not delete global canonical data. #372 is a different Capacity, the leak of call Workspaces, but it shares the Unknown mapping in the last bullet above.
  • 05-storage.md mentions Handles::reclaim_space. It does not seem to be reachable from the SDK or the operator, and I did not check whether it would release these packs.
  • I have not tried a fix. It seems to need Store-side custody of the attempt's packs, for example a pending owner row that is deleted on a definite failure plus a reclaim on open for crashed attempts. I would rather hear how you want it done first. I'm happy to send a PR for the Unknown → Capacity mapping on its own.
Lingua principale
Rust
Stelle
2.1k
Fork
110
Merge medio
23h 52m
PR unite (30g)
138

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Ephemeral-AI-Lab/layerfs

Tutte le issue di Ephemeral-AI-Lab/layerfs

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.