会在远程文件系统上阻塞 open() 系统调用吗？答案

【问题标题】：will open() system call block on remote filesystem?会在远程文件系统上阻塞 open() 系统调用吗？
【发布时间】：2014-05-26 23:38:43
【问题描述】：

我想知道如果文件系统被挂载为远程设备，例如 CEPH 文件系统或 NFS ，并且存在某种网络故障，Linux 最新内核中的 open() 系统调用是否会阻塞？

【问题讨论】：

显然它会阻塞。查看此链接，我认为它可能会有所帮助。man7.org/linux/man-pages/man2/open.2.html

标签： c linux

【解决方案1】：

是的。多长时间取决于上行链路的速度（和状态），但您的进程或线程将阻塞，直到远程操作完成。 NFS 在这方面有点臭名昭著，一些 FUSE 文件系统处理任何具有文件句柄的阻塞，但您将阻塞 open()、read() 和 write()，通常受网络和其他因素的支配系统。

不要使用O_NONBLOCK 绕过它，否则您可能会读取或写入黑洞（无论如何它都会阻塞）。

【讨论】：

【解决方案2】：

是的，如果出现某种网络故障，尝试打开远程文件系统上的文件时，open() 调用可能会阻塞。

根据远程文件系统的挂载方式，可能只需要很长时间（几秒钟）才能确定远程文件系统不可用，并且在看似过长的时间后返回不成功，或者可能只是无限期锁定，直到远程资源再次可用（或直到映射从系统中删除）。

【讨论】：

嗯。 iOS应用程序说我回答时没有回答，但你回答的时间清楚地说明了其他情况。我去一个错误报告！（留下此评论以明确指出，对不起噪音）。据它说，没有答案。
@TimPost：我对另一个问题有一个模糊的问题，即我的答案的额外 cmets 没有及时出现在 iOS 应用程序中，所以我通过应用程序做出的回应与我所做的有点不同我有没有看到多余的 cmets。
是的，但是 O_NONBLOCK 标志正是为了不阻塞调用，如果卷不可用，内核如何使它工作，但文件名已经被 open()并返回成功状态？
有几种可能性（但是 O_NONBLOCK 是本次讨论的新内容——我最近也有另一个答案，其中 O_NONBLOCK 数字，所以当这里出现时我很惊讶）。首先，open() 本身可能会阻塞，即使在文件描述符上设置了 O_NONBLOCK 标志；在确定允许远程文件访问之前，它不能成功返回。它可能会更快地失败，但它不可能成功。 O_NONBLOCK 发挥作用的主要时间是read() 和write() 或他们的亲戚。 [...继续...]
@Nulik O_NONBLOCK 旨在允许从open() 快速返回，当您知道调用将阻塞一段确定的时间，这是我能提供的最佳示例正在打开需要一两秒钟初始化的调制解调器或串行设备。但是在那里，您正在编写一个协议，而不是应该保留的数据。你想要 open() 挂在繁忙的 I/O 上，否则你不能相信它返回的句柄。