You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Borg continues even if cache partition fills up #8666
If the partition ~/.cache/borg resides on fills up (during create), Borg still continues, producing 'file not found' errors. Happened with the latest stable v1.4.0. A solution would be to detect the situation before zero free space is left, gracefully stop and produce .checkpoint (if necessary) while also clearly informing the user of the situation.
I encountered the issue in a production environment so I'd rather not try to reproduce the exact scenario (I could try something in a VM if it helps), but I do remember some specifics which might help. First of all, the listed not-found files were cache files, not the actual files processed. After seeing errors I stopped the operation with SIGINT, deleted the allegedly corrupted cache and enlarged its storage. Listing repository contents, a consistency check and successful later backups indicate repository is fine.
Thinking about it now I'm unsure whether I also did any server-side cleanup (besides the consistency check), could that be a problem?
This should be fixed in 1.4.5 by #9854 (commit 0c6e8e1). Before that, the checkpoint code (which also writes the local cache) ran inside a backup_io('read') wrapper, so a full cache partition became per-file warnings and borg create kept going. Now an ENOSPC there is critical: borg aborts (rc 2) and rolls back the partial transaction, and the next run works once space is freed. Closing. Please reopen if you still see this with 1.4.5 or later.
Activity
ThomasWaldmann commentedon Feb 16, 2025
Can you please:
drws commentedon Mar 6, 2025
I encountered the issue in a production environment so I'd rather not try to reproduce the exact scenario (I could try something in a VM if it helps), but I do remember some specifics which might help. First of all, the listed not-found files were cache files, not the actual files processed. After seeing errors I stopped the operation with SIGINT, deleted the allegedly corrupted cache and enlarged its storage. Listing repository contents, a consistency check and successful later backups indicate repository is fine.
Thinking about it now I'm unsure whether I also did any server-side cleanup (besides the consistency check), could that be a problem?
ThomasWaldmann commentedon Mar 6, 2025
@drws I don't think a server-side cleanup should be needed if you ran into an out-of-space issue client-side.
ThomasWaldmann commentedon Nov 5, 2026
This should be fixed in 1.4.5 by #9854 (commit 0c6e8e1). Before that, the checkpoint code (which also writes the local cache) ran inside a
backup_io('read')wrapper, so a full cache partition became per-file warnings andborg createkept going. Now an ENOSPC there is critical: borg aborts (rc 2) and rolls back the partial transaction, and the next run works once space is freed. Closing. Please reopen if you still see this with 1.4.5 or later.