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

Question

整个的CoreFoundation框架源,POSIX文件系统API调用(例如open(),stat(),等人...)被包裹在一个成语其中在描述符/dev/autofs_nowait获取-与open(…, 0)- POSIX的呼叫才制成; 之后描述符是close()在范围退出之前的'd'.

• 这样做有什么好处？有什么风险？

• 获取/dev/autofs_nowait描述符是否会对任何如此包装的open()调用(例如O_NONBLOCK)的标记产生影响,或者是否受其影响？

• /dev 在我的机器上,运行OS X 10.10.5还有其他"autofs"条目:

  

  ......没有一个man页面可用.如果这些类似文件的设备可以提供这方面的好处,我将有兴趣了解它们的用途,因为它可能属于它.

---

附录:我在这个问题上找不到多少内容; 2011年的Google Plus帖子声称:

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

我不太清楚这意味着什么(他们专门讨论了如何launchd工作,FWIW)但我自己很好奇,所以我编写了一个快速的上下文管理器-Y RAII结构来试用它 - 非目标性的分析显示了POSIX的测试调用完成速度更快但在一般哈希标记内; 在我获得更多关于它如何工作的背景之后,我将用更精细的梳子来研究这种策略.

Answer 1

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

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

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

这就是这些设备所做的全部事情。问题是，在 Darwin 的实现中，即使使用或open遍历文件系统也可能会阻塞。O_NONBLOCKO_NDELAY

open您可以通过a 的操作来跟踪 vfs 中的流程vnode：

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

沿着这条路，没有处理（非）阻塞行为。