Following the findings collected in issue #17827 this PR removes the specific macOS code in favor of the generic fallback. Hence, APFS volumes with just enough free space can still complete the IBD.
ftruncate behaves erratically when used in an APFS volume, generating rev*.data files with a size considerably bigger than expected.
Using the generic method solves the problem and works for both APFS and HFS+.
ftruncate behaves erratically when used in an APFS volume, generating
rev*.data files with a size considerably bigger than expected.
Using the generic method solves the problem and works for both APFS and
HFS+.
Concept NACK. We still want to do file range allocation (edit: using the built-in functionality) even on macs. However, it looks like we are using the F_PREALLOCATE function incorrectly.
From the manpage:
0 The position modes (fst_posmode) for the F_PREALLOCATE command indicate how to use the offset field. The modes are as follows:
1
2 F_PEOFPOSMODE Allocate from the physical end of file. In this case, fst_length indicates the number of newly allocated bytes desired.
3
4 F_VOLPOSMODE Allocate from the volume offset.
we are using F_PEOFPOSMODE so we want to ignore the offset argument in
0fst.fst_length = (off_t)offset + length;
and update the ftruncate call to
0 ftruncate(fileno(file), (off_t)offset + length);
(edit: I missed the second step in my initial attempt, which resulted in truncated files and brokenness)
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.