在OS X上使用/ dev / autofs_nowait的风险和回报

Question

在整个CoreFoundation framework source中，POSIX文件系统API调用（例如open()，stat()等等）是wrapped in an idiom，其中在进行POSIX调用之前，使用/dev/autofs_nowait获取open(…, 0)上的描述符;之后，在范围退出之前，描述符是close()'d。

• 这样做有什么好处？有什么风险？
• 获取/dev/autofs_nowait描述符是否对任何如此包装的open()调用（例如O_NONBLOCK）的标记有任何影响，或者是否受其影响？
• 在我的机器上运行OS X 10.10.5的/dev还有其他“autofs”条目： ......没有一个有man页面可用。如果这些类似文件的设备可以提供这方面的好处，我将有兴趣了解它们的用途，因为它可能属于它。

---

附录：我在这个问题上找不到多少内容;一个Google Plus post from 2011声称：

[t]他的文件是一个特殊设备，由内核中的autofs文件系统实现监视。打开时，autofs文件系统不会在autofs文件系统上的任何I / O操作上阻止该进程。

我不太清楚这意味着什么（他们专门讨论launchd是如何工作的，FWIW）但我自己很好奇，所以我写了a quick context-manager-y RAII struct到try it out - 无目标的分析显示测试与POSIX调用完成更快但在一般的hashmarks;在我获得更多关于它如何工作的背景之后，我将用更精细的梳子来研究这种策略。

Answer 1

这些设备允许实现者避免为功能定义新的syscall或ioctl，也许它是以这种方式实现的，因为它更简单，需要更新更少的代码，并且不会更改VFS API，这可能是当时的担忧。

当你打开/dev/autofs_nowait并遍历一个路径时，你会触发自动挂载，但不要等待它们完成（否则你的进程会阻塞，直到文件系统挂载或操作超时），所以你可能会在打开时收到ENOENT即使一切都很好，一个文件。

OTOH，/dev/autofs_notrigger使得该过程甚至不会触发自动安装。

这就是所有这些设备所做的。问题是，在Darwin的实现中，open可能会在遍历文件系统时阻塞，即使使用O_NONBLOCK或O_NDELAY。

您可以按照来自vfs的流程，来自open的vnode操作：

• vn_open - > vn_open_auth - >
• namei - > lookup - > ...

在该路径下，没有处理（非）阻塞行为。