直接I/O是拷贝较大文件的最高效方式，因此我希望将该功能添加到一个程序中。
Windows在Win32的CreateFileA()中提供了FILE_FLAG_WRITE_THROUGH和FILE_FLAG_NO_BUFFERING。自Linux 2.4.10起，open()有O_DIRECT标志。
是否有一种可移植的POSIX方法可以实现相同的结果? 就像Win32 API在Windows XP到Windows 11上的工作方式一样，在所有UNIX类系统中进行直接I/O，并以一种可靠的可移植方式。
没有POSIX标准支持直接IO。
截至2023年1月，至少存在两种不同的API和行为。Linux、FreeBSD和显然IBM的AIX使用O_DIRECT标志来执行open()，而Oracle的Solaris则在已打开的文件描述符上使用directio()函数。
Linux对POSIX open()函数中O_DIRECT标志的使用在Linux open()手册页中有记录：
O_DIRECT（自Linux 2.4.10起）尝试最小化对此文件进行I/O的缓存效应。通常情况下，这会降低性能，但在特殊情况下非常有用，例如应用程序自己进行缓存https://en.wikipedia.org/wiki/QFSwhen时。文件I/O直接完成到/从用户空间缓冲区。单独使用
O_DIRECT标志会努力实现数据同步传输，但不提供O_SYNC标志的保证，即数据和必要元数据将被传输。为保证同步I/O，必须除了使用O_DIRECT外还需使用O_SYNC。有关详细讨论，请参见下面的NOTES。
Linux没有明确指定直接IO如何与同一文件上打开的其他描述符交互，或者使用mmap（）映射文件时会发生什么；也没有对直接IO读取或写入操作的对齐或大小限制。根据我的经验，这些都是特定于文件系统的，并且随着时间的推移而改进/变得不那么受限制，但大多数Linux文件系统需要页面对齐的IO缓冲区，而许多（多数？所有？）（曾经？现在仍然？）需要页面大小的读取或写入。
FreeBSD遵循Linux模型：通过将 O_DIRECT 标志传递给 open（）：
O_DIRECT可用于最小化或消除读写的缓存效应。 系统将尝试避免缓存您读取或写入的数据。 如果它无法避免缓存数据，则会将数据对缓存的影响最小化。 不慎使用此标志会严重降低性能。
OpenBSD不支持直接IO。在OpenBSD的open()或OpenBSD的'fcntl()`手册中都没有提到直接IO。
IBM的AIX 似乎支持Linux类型的O_DIRECT标志来执行open(), 但实际发布的IBM AIX手册似乎并不普遍可用。
SGI的Irix也支持Linux风格的O_DIRECT标志来执行open()：
O_DIRECT若设定，则所有在此文件描述符上进行的读写操作都将直接执行到/从用户程序缓冲区，前提是满足适当的大小和对齐要求。有关如何确定对齐约束条件的信息，请参见
fcntl(2)手册中的F_SETFL和F_DIOINFO命令。O_DIRECT是 Silicon Graphics 扩展，仅受支持于本地 EFS 和 XFS 文件系统以及远程 BDS 文件系统。
值得注意的是，在 Linux 上的 XFS 文件系统起源于 SGI 的 Irix。
Solaris 使用了完全不同的接口。Solaris 使用 特定的directio() 函数，以在每个文件上设置直接 IO：
mmap()映射，那么该文件的直接IO将被完全禁用。
* - 这并不是完全正确的 - 如果您正在使用SAMFS或QFS文件系统以共享模式，并从文件系统的活动元数据控制器（其中文件系统必须通过Solaris forcedirectio挂载选项进行挂载，以便在群集中的一个系统上通过直接IO完成所有访问），如果您使用directio(fd, DIRECTIO_OFF)禁用文件的直接IO，则会损坏文件系统。如果您在QFS元数据控制器上进行数据库恢复，Oracle自己的顶级RAC数据库就会这样做，您将最终得到一个损坏的文件系统。