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-...@openjdk.java.net; Kaczmarek, Eric; core-libs-dev@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 --