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

Abierto
  • ¿Algo no está bien?
#379 2 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@jiangkoumo ya está trabajando en esto.

Desde el 8/11/2026.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
43/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
linux, rust, sqlite
Área
backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Rust
Estrellas
2.1k
Forks
110
Merge medio
23 h 52 min
PR fusionados (30 d)
138

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Ephemeral-AI-Lab/layerfs

Todos los issues de Ephemeral-AI-Lab/layerfs

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.