Proposal for adding O_DIRECT support into JDK 9

[ecki at zusammenkunft.net]

The question is, if support for fadvice() would be more flexible (and somewhat saner).

And of course real async fio .)

Gruss
Bernd
-- 
http://bernd.eckenfels.net

Von: Alan Burlison
Gesendet: Donnerstag, 13. Oktober 2016 14:30
An: Brian Burkhalter; Lu, Yingqi
Cc: nio-dev at openjdk.java.net; Kaczmarek, Eric; core-libs-dev at openjdk.java.net; Kharbas, Kishor
Betreff: Re: Proposal for adding O_DIRECT support into JDK 9

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
--