direct_io 失败的原因答案

【问题标题】：Reasons for direct_io failuredirect_io 失败的原因
【发布时间】：2012-10-29 04:21:37
【问题描述】：

我想知道在什么情况下直接 I/O 传输会失败？

为此，我有以下三个子查询。根据“了解 Linux 内核”一书..

Linux 提供了一种绕过页面缓存的简单方法：直接 I/O 传输。在每次 I/O 直接传输中，内核对磁盘控制器进行编程，以将数据直接从属于自缓存应用程序的用户模式地址空间的页面传输到/传输。

-- 所以要解释失败，需要检查应用程序是否具有自缓存功能？不知道怎么做。

2.此外，书中说“当自缓存应用程序希望直接访问文件时，它会打开指定 O_DIRECT 标志的文件。在为 open() 系统调用提供服务时，dentry_open() 函数会检查 direct_IO方法是针对正在打开的文件的address_space对象实现的，反之则返回错误码”。

-- 除此以外还有什么其他原因可以解释直接 I/O 故障？

3.这个命令“dd if=/dev/zero of=myfile bs=1M count=1 oflag=direct”会不会在 linux 中失败（假设有足够的可用磁盘空间）？

【问题讨论】：

【解决方案1】：

底层文件系统和块设备必须支持O_DIRECT 标志。此命令将失败，因为 tmpfs 不支持 O_DIRECT。

dd if=/dev/zero of=/dev/shm/test bs=1M count=1 oflag=direct

写入大小必须是底层驱动程序块大小的乘积。此命令将失败，因为 123 不是 512 的乘积：

dd if=/dev/zero of=myfile bs=123 count=1 oflag=direct

【讨论】：

【解决方案2】：

直接 I/O 会继续失败的原因有很多。

所以要解释失败，需要检查应用程序是否具有自缓存功能？

您不能在外部执行此操作 - 您可以从源代码中推断出这一点，或者观察程序在运行时如何使用资源（我猜是二进制反汇编）。这更多是程序如何工作的属性，而不是“在调用中打开此功能”。认为所有使用 O_DIRECT 的程序都有自我缓存是一个危险的假设（从概率上我会说它更有可能，但你不确定）。

有严格的requirements for using O_DIRECT and they are mentioned in the man page of open (see the O_DIRECT section of NOTES)。
对于现代内核，正在操作的区域必须与磁盘块大小对齐，并且其大小必须是磁盘块大小的倍数。未能正确执行此操作甚至可能导致静默回退到缓冲 I/O。
是的，例如尝试在文件系统（例如tmpfs）上使用它不支持O_DIRECT。我想如果到磁盘的路径由于某种原因返回故障（例如，磁盘正在死去，并且与写回发生的情况相比更快地返回错误），它也可能会失败。

【讨论】：