macOS: transaction-log flush uses fsync, which does not flush the drive cache; use F_FULLFSYNC
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 55/100
Research direction
Start in src/binding/transaction_log/transaction_log_file_posix.cpp and trace TransactionLogFile::flush() through the macOS branch; then locate the other log and marker file sync calls, including append-boundary markers and txn.state. Check which errors indicate that F_FULLFSYNC is unsupported and how existing callers handle sync failures. Done means macOS requests a drive-cache flush with F_FULLFSYNC, falls back to fsync() where unsupported, and applies this to the relevant log and marker files.
Written by the indexing model from the issue text.
Description
Problem
On macOS, TransactionLogFile::flush() syncs a transaction-log segment with fsync() (src/binding/transaction_log/transaction_log_file_posix.cpp, the __APPLE__ branch). On macOS fsync() moves data to the drive but does not ask the drive to flush its write cache, so the bytes can still be lost on power loss. Apple documents fcntl(fd, F_FULLFSYNC) as the call that flushes the cache.
This flush is what databaseFlushBegin() relies on to make log entries durable before RocksDB flushes the matching data. On macOS a power loss can therefore leave flushed data whose log entries are gone, so replication and audit readers miss them.
Fix
On macOS use fcntl(fd, F_FULLFSYNC), and fall back to fsync() when the filesystem reports F_FULLFSYNC as unsupported (some network and FUSE filesystems). The same applies to any other place that fsyncs log or marker files on macOS, such as the append-boundary markers and txn.state.
Notes
- This affects power loss only, not a process crash, and only on macOS, which is mostly a development platform here.
- Found while planning a durable abort fence for transaction-log abort markers (harper#3253). That fence needs the same call.
— Claude Opus 5.5 (dev-agent)
- Dominant language
- C++
- Stars
- 24
- Forks
- 3
- Avg merge
- 1d 6h
- Merged PRs (30d)
- 59
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from HarperFast/rocksdb-js
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
HarperFast/rocksdb-js#983 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
HarperFast/rocksdb-js#964 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
HarperFast/rocksdb-js#945 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 58/100
HarperFast/rocksdb-js#986 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
HarperFast/rocksdb-js#984 ·
Maintainers usually reply within 1 day
All issues in HarperFast/rocksdb-js
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
sandialabs/Fenix#172 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
scp-fs2open/fs2open.github.com#7953 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
SteveMacenski/slam_toolbox#907 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day