On Thu, Jan 9, 2025 at 11:16 AM Travis Downs <travis.downs@xxxxxxxxx> wrote: > > On Thu, Jan 9, 2025 at 1:57 AM Theodore Ts'o <tytso@xxxxxxx> wrote: > > > > Don't do that. Really. > > > > First of all, your program might need to run on OS's other than Linux, > > such as Legacy Unix systems, Mac OS X, etc, and officially, there is > > zero guarantees about cache coherency between O_DIRECT writes and the > > page cache. So if you use O_DIRECT I/O and buffered I/O or mmap > > access to a file.... all bet are off. > > Thanks Theodore for your comprehensive reply. I probably was not very > clear in the way I posed my question. To clarify: > > - There is only one process involved here making all the writes > - We do only O_DIRECT reads and writes, so I don't expect the page > cache to be involved in the usual case (but we can't exclude it entirely). > - So the question is large about the possible outcomes of doing a zero- > copy O_DIRECT write (where the block driver will ultimately be reading > directly from the pages allocated by and passed to the kernel by the > userspace application) in the situation where a portion of the the passed > pages are modified in a racy way by the userspace application by a > subsequent O_DIRECT write. Sorry, the last point above is totally wrong (insert excuse about coffee, etc here). What it should say is "...where a portion of the passed pages are modified in-memory by the application while the write is in flight". That is, there is only one O_DIRECT write here. It is issued, and before it completes the userspace writes into the same buffers that were passed to the O_DIRECT write, modifying some (but not all) bytes. Do we have a guarantee that the unmodified bytes will be successfully written? Can is cause some corruption/inconsistency in the FS or block layer? TIA
