我将在 FUSE 中实现一个文件系统，然后在内核中实现。我不知道如何使用 Direct IO。不同的消息来源强调了该标志所暗示的不同内容。
文件系统忽略 O_DIRECT 是否安全？
- 读取和写入操作将像平常一样进行。 Open 会忽略它并且不会失败。
- 数据校验和仍将得到验证。因此，即使硬盘返回正常，读取操作也可能因校验和而失败。
- 写入的数据将受到写入时复制和延迟分配的影响。
- 写操作将立即返回 OK。写回会在延迟后发生，或者在断电的情况下永远不会发生。耐久性无法得到保证，但无论如何这是 O_SYNC 语义的。
我想到的问题很少。
- 据我了解，在缓冲区/页面缓存中缓存文件内容是 VFS 的责任，而不是文件系统的责任。 VFS 也解释这个标志吗？
- 根据一个答案，标志在未来的内核上可能会失败。答案下的评论解释说 Direct IO 与数据日志模式相反。
答案1
根据open(2) 手册页:
O_DIRECT (since Linux 2.4.10)
Try to minimize cache effects of the I/O to and from this
file. In general this will degrade performance, but it is
useful in special situations, such as when applications do
their own caching. File I/O is done directly to/from user-
space buffers. The O_DIRECT flag on its own makes an effort
to transfer data synchronously, but does not give the
guarantees of the O_SYNC flag that data and necessary metadata
are transferred. To guarantee synchronous I/O, O_SYNC must be
used in addition to O_DIRECT. See NOTES below for further
discussion.
从注释部分：
O_DIRECT support was added under Linux in kernel version 2.4.10.
Older Linux kernels simply ignore this flag. Some filesystems may
not implement the flag and open() will fail with EINVAL if it is
used.
所以 O_DIRECT 曾经被简单地忽略。和来自 LKML，就在几个月前：
只要不损坏数据，谁会关心文件系统如何实现 O_DIRECT？在许多情况下，ext3 都会回退到缓冲 IO，但对此唯一的抱怨是性能。 IOWs，长期以来，如果用户关心 O_DIRECT表现那么他们必须小心选择文件系统。
但如果每个文件系统只有 5 行代码来支持 O_DIRECT 正确地通过缓冲 IO，那么到底为什么用户空间必须跳过障碍来显式处理 open(O_DIRECT) 失败呢？
特别是当你考虑到他们所能做的就是退回到缓冲 IO 本身时......
我曾为所有这些写过反对意见，但我想了更好的办法。旧版本的内核只是忽略 O_DIRECT，所以显然有先例。
鉴于此，您似乎可以安全地忽略它。关键词似乎是“不损坏数据”。
目前。
另请注意，您的链接问题有答案说 O_DIRECT 出于性能原因没有用。这是完全错误的。通过页面缓存传递数据比不是通过页面缓存传递它。这对于每秒能够传输千兆字节的硬件来说非常重要。如果您只处理每一位数据一次，那么缓存实际上是无用的，但它会不必要地影响整个系统。
自从我编写 Linux 文件系统模块以来已经有几年了。不幸的是我不记得 VFS 系统如何处理缓存。