Repository navigation
durability: fsync the parent directory after creating the .graph/WAL and after deleting the WAL #389
Description
Problem
On Linux and other POSIX systems, a new file, a deleted file or a renamed file survives a power loss only after its parent directory is fsynced. I could not find a directory fsync in src/storage/backend/file.rs or src/wal.rs. The only calls I found are sync_all() and sync_data() on file handles.
Possible outcomes after a power loss (not a process kill):
- A new
.graphfile, or a new<db>.wal, is missing even though writes to it were fsynced. - The WAL deleted by
checkpoint()comes back. Replay should be idempotent, but this path is not tested.
The SIGKILL test cannot find this, because a process kill does not drop the OS page cache.
Ask
- After creating the database file or the WAL, and after removing the WAL, open the parent directory and call
sync_all()on it. Skip this on Windows, where it is not needed and not supported. - Add a test that uses the fault-injection backend or a mock filesystem to check the call order. If that is not practical, write the durability order down in the durability doc (filed separately).
- Please first confirm that no directory sync exists somewhere I missed.
Activity
docs(roadmap): make v2.0.2 the final v2.x release, split v3.0.0/v3.1.0 (
fix(durability): fsync the parent directory after creating the .graph…
Merge pull request #412 from project-minigraf/merge/main-into-v3
release: v2.0.2 — final planned v2.x release