在 Linux 上使用 O_DIRECT

Question

如果这个问题过于面向程序员，请告诉我。我想知道是否有人熟悉Linux 2.6上open()系统调用的O_DIRECT标志？Linus 贬低它的使用，但高性能文件写入似乎表明它的使用。我想知道任何现实世界的经验和建议。

更多信息：我正在使用的应用程序确实维护着自己的缓存，这样做的速度平均提高了 5 倍或更多。写入文件时，缓存的内容必须写出到文件系统缓存，这似乎是多余的，而且是一个性能问题。

Answer 1

好吧，你问的是经验，这使得这个问题有点主观和争论，但还可以。

Linus 说，指的是人们通常认为 O_DIRECT 的用途，对于这些用途，IMO Linus 大部分是正确的。即使您进行直接 I/O，您也无法将数据直接从设备传输到/从设备到您的程序语句，您需要一个填充（由程序或设备）并通过系统调用传输到另一端的缓冲区。此外，为了提高效率，您不会想重读刚刚读过的东西，以防再次需要。所以你需要某种缓存......而这正是内核在没有 O_DIRECT 的情况下提供的，页面缓存！为什么不使用它？如果更多的进程想要同时访问同一个文件，它也会带来好处，这将是 O_DIRECT 的灾难。

话虽如此，O_DIRECT 有它的用途：如果由于某种原因您需要直接从块设备获取数据。它与性能无关。

使用 O_DIRECT 来提高性能的人通常来自具有糟糕页面缓存算法的系统，或者没有 POSIX 建议机制的系统，或者甚至是人们无意识地重复其他人所说的话。为了避免这些问题，O_DIRECT 是一个解决方案。Linux，OTOH，有一个哲学，你应该解决真正的潜在问题，而潜在的问题是操作系统在页面缓存方面做得不好。

我将 O_DIRECT用于 cat 的简单实现，以在我的机器中查找内存错误。这是 O_DIRECT 的一种有效用途。这与性能无关。

Answer 2

其实，O_DIRECT 是需要避免任何的

• 缓存污染——有时你知道缓存的开销没有意义，例如在处理非常大的文件时，比如只有 2 GiB 的 RAM 时，比如 64 GiB。用户决定验证的 32 GiB 的 Torrent 文件似乎不是缓存的好候选。这只是额外的活动，有自己的开销。它可能会导致从缓存中删除一些非常有用的数据。
• 双缓存——例如一些 RDBMS（提到 MySQL）允许定义自己的缓存。数据库应该比内核的虚拟内存更了解如何缓存和什么，而内核的虚拟内存对 SQL 规划等一无所知。

——这似乎不好。而O_DIRECT并不意味着要快，往往是没有。

Answer 3

请注意，O_DIRECT在具有较新文件系统的较新内核中使用可能会失败。例如，请参阅此错误报告。因此，这种用法不仅常常令人怀疑，而且在下一代 Linux 发行版中可能根本无法使用。所以我不会把我的代码的性能押在它上面，即使你碰巧能够证明它可能有好处。

Answer 4

它与性能有很大关系。

一个有趣的例子是在 mongodb 中使用 mmap 引擎。正如其他人所说，最好使用 O_DIRECT，在一段时间内不太可能读取数据。在 mongodb 中，数据库日志使用 O_DIRECT 写入，而数据和索引写入由页面缓存机制 (pdflush) 处理，因为虽然 O_DIRECT 提供更少的带宽，但也意味着更少的延迟，因此减少了数据丢失的情况意外中断（内核崩溃、磁盘或电源故障）。请注意，在将 O_DIRECT 写入提交到非易失性存储之前仍有缓冲，这只会减少数据丢失。

O_DIRECT 的另一个重要特性是它提供了对写入顺序的更多控制。同样，它不能保证写入的顺序（除非您有一个非易失性缓存磁盘控制器并使用 fifo 调度程序，但这些都有其自身的复杂性）。因此，尽管 mysql 将 O_DIRECT 用于其数据/索引以及日志记录，但可以预期后者通常会首先提交。

但重要的是要记住 O_DIRECT 破坏了资源分配的公平性。您的应用程序加速的原因之一是它正在减慢其他东西。

Answer 5

关于@Juliano 已经说过的话。

检查posix_fadvise真正的问题是否是底层文件系统的缓存算法的错误行为，您可以尝试给它建议，您将如何使用文件系统。对于良好实现的 fs，它应该会提高性能。（这里是涉及类似考虑因素的另一个主题的链接/sf/answers/262907291/）