On 06/10/2016 00:31, Brian Burkhalter wrote:

Given that the functionality of O_DIRECT on Linux appears to be
supported by other interfaces on OS X, Solaris, and Windows, I wonder
whether the patch will need to be refactored in some way to
accommodate these other operating systems? For reference it looks as
if direct I/O on OS X uses the F_NOCACHE command of fcntl(2) [1]
(although per some online comments this might have some problems),
Solaris uses the advice argument of directio(3c) [2], and Windows
uses a combination of flags passed to CreateFile() [3, 4].

The Linux open(2) manpage contains a long list of warnings about O_DIRECT, including:

In Linux alignment restrictions vary by filesystem and kernel version and might be absent entirely. However there is currently no filesystem-independent interface for an application to discover these restrictions for a given file or filesystem.

O_DIRECT I/Os should never be run concurrently with the fork(2) system
call, if the memory buffer is a private mapping (i.e., any
mapping created with the mmap(2) 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) is called. Failure to do so can result in data corruption
and undefined behavior in parent and child processes.

Applications should avoid mixing O_DIRECT and normal I/O to the same
file, and especially to overlapping byte regions in the same file.
Even when the filesystem correctly handles the coherency issues in
this situation, overall I/O throughput is likely to be slower than
using either mode alone. Likewise, applications should avoid mixing
mmap(2) of files with direct I/O to the same files.

 "The thing that has always disturbed me about O_DIRECT is that
the whole interface is just stupid, and was probably designed
by a deranged monkey on some serious mind-controlling
substances." - Linus

Adding support for O_DIRECT has a far wider impact than adding just another IO handle flag. As such I'm opposed to this change as it seems to be prone to cause hard-to-diagnose failures on Linux and it is also specific to just Linux.

Alan Burlison

Reply via email to