Skip to content

restore: Don't hang on a filesystem that never preallocates (v0.18.0) - #1

Closed
msaggiorato wants to merge 2 commits into
masterfrom
fix/preallocation-cannot-hang-the-restore
Closed

msaggiorato wants to merge 2 commits into
masterfrom
fix/preallocation-cannot-hang-the-restore

Conversation

@msaggiorato

@msaggiorato msaggiorato commented Sep 16, 2026

Copy link
Copy Markdown
Member

The branch a fleet build is cut from: the same change as #2, applied to internal/fs on top of the v0.18.0 tag, because that is the version the maintenance action downloads. Review the fix and its evidence in #2.

Nothing is published yet. A release here would be tagged v0.18.0-saucal.1 with restic_0.18.0_linux_amd64.bz2 + SHA256SUMS, and SAUCAL_RESTIC_RELEASE_BASE pointed at it org-wide. Until then, restores on Pressable hosts still hang.

🤖 Generated with Claude Code

https://claude.ai/code/session_017d5y4KNmm2N5ySPPH1H49Z

@msaggiorato msaggiorato reopened this Sep 16, 2026
@msaggiorato
msaggiorato force-pushed the fix/preallocation-cannot-hang-the-restore branch from 7789b27 to 4ccd204 Compare September 17, 2026 01:26
@msaggiorato msaggiorato changed the title restorer: Don't hang the restore when preallocation never returns restore: Don't hang on a filesystem that never preallocates (v0.18.0) Sep 17, 2026
@msaggiorato
msaggiorato force-pushed the fix/preallocation-cannot-hang-the-restore branch from 4ccd204 to bc21fbe Compare September 17, 2026 01:30
The restorer reserves space for each file before filling it, so that writing its
blobs out of order does not fragment it. Some sandboxed filesystems, seen on
managed WordPress hosting, accept that syscall and never answer it, and the
consequences run deeper than a slow restore: the kernel holds the inode lock
while it waits, so the file can no longer be written, shortened or unlinked —
unlinking it blocks in turn, and takes its directory with it — and the waiting
thread cannot be interrupted, not even by SIGKILL, so the process it belongs to
can never exit. A restore stopped at the first file that needed data, left it
empty, and printed nothing.

Making the call is therefore an irreversible commitment, and no deadline around
it can take one back: by the time the deadline passes, that file and that
process are already lost. Ask the filesystem beforehand instead, with a
throwaway file whose name is unlinked before the call, from a process that
exists only to ask — so a filesystem that never answers strands that process
instead of the restore. The answer is kept per filesystem. Whether the call
succeeded is not the question, only whether it came back at all: one that fails
does so promptly, and the caller tolerates a failure anyway.

This is the v0.18.0 branch a fleet build is cut from; the same change sits in
internal/fileio on the master-based branch.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017d5y4KNmm2N5ySPPH1H49Z
@msaggiorato
msaggiorato force-pushed the fix/preallocation-cannot-hang-the-restore branch from bc21fbe to e1385fd Compare September 17, 2026 01:34
@github-actions github-actions Bot added size/XL and removed size/L labels Sep 17, 2026
The hosts install restic from SAUCAL_RESTIC_RELEASE_BASE, which until now meant
building and uploading the assets by hand. Add the script that builds them, the
workflow that publishes them when a v*-saucal.* tag is pushed, and the notes for
whoever changes this branch next.

The script refuses a dirty working tree: Go stamps the build with the tree's
state, so the same commit built with stray files around yields a different binary
than one built clean, and a release has to be reproducible from its tag.

Also fix this branch's own CI the way master's was fixed, so changes here can be
tested: the open source MinIO server is archived and dl.minio.io answers every
download with "410 Gone".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017d5y4KNmm2N5ySPPH1H49Z
@msaggiorato
msaggiorato force-pushed the fix/preallocation-cannot-hang-the-restore branch from 2278fd1 to eada6b6 Compare September 17, 2026 13:47
@msaggiorato

Copy link
Copy Markdown
Member Author

Superseded by release/saucal, which carries the same fix on restic 0.19.1 — the bug is present and reproduced on 0.19.1 too, so there is no reason to ship a fix on a release from March 2025.

@msaggiorato
msaggiorato deleted the fix/preallocation-cannot-hang-the-restore branch September 17, 2026 14:41
msaggiorato added a commit that referenced this pull request Sep 17, 2026
The file named pull request #1, which has been closed for a while, so the
branch the fleet installs was getting no test matrix at all — pushes to
anything but master are ignored by the workflow. Name the replacement and
say what goes wrong if it is closed too.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017d5y4KNmm2N5ySPPH1H49Z
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant