O_DIRECT I/Os possibly affected by fork() (use_direct_reads, use_direct_io_for_flush_and_compaction)
- Dominant language
- C++
- Stars
- 32.1k
- Forks
- 6.9k
- Avg merge
- 32m
- Merged PRs (30d)
- 1
Description
From `open` man page: https://man7.org/linux/man-pages/man2/open.2.html
> O_DIRECT I/Os should never be run concurrently with the [fork(2)](https://man7.org/linux/man-pages/man2/fork.2.html)
system call, if the memory buffer is a private mapping (i.e., any
mapping created with the [mmap(2)](https://man7.org/linux/man-pages/man2/mmap.2.html) MAP_PRIVATE flag; this includes
memory allocated on the heap and statically allocated buffers).
Any such I/Os, whether submitted via an asynchronous I/O
interface or from another thread in the process, should be
completed before [fork(2)](https://man7.org/linux/man-pages/man2/fork.2.html) is called. Failure to do so can result
in data corruption and undefined behavior in parent and child
processes. This restriction does not apply when the memory
buffer for the O_DIRECT I/Os was created using [shmat(2)](https://man7.org/linux/man-pages/man2/shmat.2.html) or
[mmap(2)](https://man7.org/linux/man-pages/man2/mmap.2.html) with the MAP_SHARED flag. Nor does this restriction
apply when the memory buffer has been advised as MADV_DONTFORK
with [madvise(2)](https://man7.org/linux/man-pages/man2/madvise.2.html), ensuring that it will not be available to the
child after [fork(2)](https://man7.org/linux/man-pages/man2/fork.2.html).
This seems to suggest that creating any child process, e.g. with system(), from a RocksDB process using direct I/O is unsafe.
Contributor guide
Assessment
This issue has not been assessed yet.