fs: use ftruncate on OpenBSD in AllocateFileRange #36189

pull HouseOfHufflepuff wants to merge 1 commits into bitcoin:master from HouseOfHufflepuff:fs-openbsd-ftruncate-allocatefilerange changing 1 files +4 −0

HouseOfHufflepuff commented at 1:29 AM on September 8, 2026: contributor
Summary

OpenBSD provides neither fallocate nor posix_fallocate, so AllocateFileRange() always fell through to the slow fallback path there: writing the entire range one 64KiB buffer at a time instead of just advising the OS of the eventual file size.

This adds an __OpenBSD__ branch that uses ftruncate, matching the guidance in #32643 and the same pattern already used for the macOS branch just above it in this function.

Fixes #32643

Test plan

I don't have OpenBSD hardware to run this on directly, so it's verified by:
- The "OpenBSD Cross" CI job, which compiles this exact branch for the target and passes.
- Full local build (macOS, Clang) with no new warnings.
- Full unit test suite (test_bitcoin, 825 cases) passes.
- test/lint/lint-files.py, lint-includes.py, and lint-locale-dependence.py all pass.
The approach mirrors a previous attempt at this issue (#32645, closed unmerged) which was hand-tested on real OpenBSD 7.7 via a signet IBD run, confirming the fallback path is no longer hit.

fs: use ftruncate on OpenBSD in AllocateFileRange

OpenBSD doesn't provide fallocate or posix_fallocate, so
AllocateFileRange() was always taking the slow fallback path there,
writing the whole range one 64KiB chunk at a time.

ftruncate is available and, like on the other platforms handled here,
is sufficient to advise the OS of the eventual file size in the
non-Windows, non-macOS case.

Fixes #32643

cafd88ca4a

DrahtBot commented at 1:29 AM on September 8, 2026: contributor



The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.



Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/36189.



Reviews

See the guideline and AI policy for information on the review process.

Type Reviewers

Approach NACK winterrdog

If your review is incorrectly listed, please copy-paste <code></code> into the comment that the bot should ignore.
sedited commented at 11:10 AM on September 8, 2026: contributor

Please don't post LLM PR descriptions. That "Test Plan" doesn't tell anything besides the bare minimum required to make CI pass.
HouseOfHufflepuff commented at 5:11 PM on September 8, 2026: contributor

Ready for review: @theStack @fanquake
in src/util/fs_helpers.cpp:234 in cafd88ca4a
```
 227 | @@ -228,6 +228,10 @@ void AllocateFileRange(FILE* file, unsigned int offset, unsigned int length)
 228 |      // Version using posix_fallocate
 229 |      off_t nEndPos = (off_t)offset + length;
 230 |      if (0 == posix_fallocate(fileno(file), 0, nEndPos)) return;
 231 | +#elif defined(__OpenBSD__)
 232 | +    // OpenBSD doesn't have fallocate or posix_fallocate, use ftruncate instead
 233 | +    off_t nEndPos = (off_t)offset + length;
 234 | +    if (0 == ftruncate(fileno(file), nEndPos)) return;
```
winterrdog commented at 9:35 PM on September 8, 2026:

some thoughts && questions on this:

1. on the shrink safety (data loss/clobbering):

posix_fallocate() (plus other cases besides fallback) never shrinks the file: if offset + len is already within the current file size, it is effectively a no-op. that's what i'm trying to preserve in #35524 for the fallback (and Windows) case to fix #33164

ftruncate() does not have that property. if nEndPos is smaller than the current file size, it will actually shrink the file and discard the data past nEndPos -- sth AllocateFileRange() shoud avoid doing based on how it's supposed to work

so, can we guarantee that nEndPos is never smaller than the current file size when we hit the OpenBSD case ?

2. on the sparse-file / preallocation-intent footgun:

AllocateFileRange()'s intent is to preallocate (a disk optimisation technique), but on OpenBSD this case is just ftruncate(). that only extends the logical file size (see #17827 about how confusing this can be); it does not necessarily allocate the underlying disk blocks, so the new region can be a sparse hole. right now, that means on OpenBSD, a full disk won't be caught by ftruncate -- it gets deferred to whatever later write() actually touches that hole, which is not a great place to discover that you are out of space (partial writes, error handling scattered elsewhere, etc..). also, note that a sparse-then-filled-in region is more likely to get fragmented by the filesystem's allocator than a range that was reserved contiguously ahead of time (AOT), which can matter for IBD/reindex read performance (not a bug, just impacts performance in a "not-so-good" way)

now, that is different from what posix_fallocate() guarantees: it reserves the space up front, so once it succeeds, subsequent writes into that range (physical size grows as a result) should never fail with ENOSPC

so are we OK with the OpenBSD fallback weakening that guarantee ?

i'd love to hear your thoughts

a few refs:

https://forums.freebsd.org/threads/using-posix_fallocate-from-userland.68282/

https://reviews.llvm.org/D38295 - claims fallocate is faster than posix_fallocate which is backed by the man page too; but fallocate is linux-specific (this is besides the point but i found it interesting and thought someone else might as well)

https://stackoverflow.com/questions/14063046/fallocate-vs-posix-fallocate
winterrdog commented at 12:36 PM on September 10, 2026: contributor

from the looks of it, this PR is not going to fly anywhere with the current approach, since OpenBSD does not expose anything like fallocate/posix_fallocate/F_PREALLOCATE with equivalent disk-space reservation semantics

the current ftruncate branch can actively defeat the generic fallback below it. ftruncate() only changes the logical file size (inode size get changed, not actual blocks), so it can succeed even when there is not enough disk space to back the newly extended range. because of that, if (0 == ftruncate(...)) return; will normally return successfully without actually allocating the blocks, so the code never reaches the fallback that writes zero-filled buffers across the range and forces the blocks to actually get allocated

right now, i think the cleanest fix is to drop the __OpenBSD__ branch entirely and let it fall through to the existing fallback.

also see: #32643 (comment)

friendly ping: @fanquake @kallewoof -- any chance you got time to weigh in here ?

for me, it's an approach NACK
HouseOfHufflepuff commented at 4:42 PM on September 14, 2026: contributor

You're right, thanks for digging into this — a shrink-guard wouldn't have been enough anyway since the real problem is ftruncate() succeeding without ever forcing block allocation, which skips the fallback that actually does. There's no OpenBSD syscall with real posix_fallocate() semantics, so I don't think this is fixable as an approach. Closing.
HouseOfHufflepuff closed this on Sep 14, 2026

Type	Reviewers
Approach NACK	winterrdog

Contributors

Linked (view graph)

#32643 fs: use `ftruncate` on OpenBSD in `AllocateFileRange`#32645 fs: use `ftruncate` in `AllocateFileRange` on OpenBSD

fs: use ftruncate on OpenBSD in AllocateFileRange #36189

Summary

Test plan

Code Coverage & Benchmarks

Reviews

a few refs: