Risks and rewards of using /dev/autofs_nowait on OS X

Question

Throughout the CoreFoundation framework source, POSIX filesystem API calls (e.g. open(), stat(), et al…) are wrapped in an idiom wherein a descriptor on /dev/autofs_nowait is acquired – with open(…, 0) – before the POSIX calls are made; afterwards the descriptor is close()’d before the scope exits.

• What is the benefit of doing this? What are the risks?

• Does acquiring the /dev/autofs_nowait descriptor have any affect on, or is it effected by, flags to any thusly-wrapped open() calls (like e.g. O_NONBLOCK)?

• /dev on my machine, running OS X 10.10.5 has other “autofs” entries:

  … none of which have man pages available. If these file-like devices might offer benefits in this vein I would be interested to hear about their use as well, as it may pertain.

---

Addendum: I could not find much on this subject; a Google Plus post from 2011 claims that:

[t]his file is a special device that's monitored by the autofs filesystem implementation in the kernel. When opened, the autofs filesystem will not block that process on any I/O operations on an autofs file system.

I am not quite sure what that means (they were specifically talking about how launchd works, FWIW) but I was curious about this myself, so I wrote a quick context-manager-y RAII struct to try it out – untargeted profiling shows tests with POSIX calls completing faster but within general hashmarks; I’ll investigate this tactic with a finer-toothed comb after I get more background on how it all works.

Danieldaniela

If this works on a per-process basis, this may cause undesirable behavior in other threads that don't want the inhibition. – Divisionism

@Divisionism Good to know, thanks. – Danieldaniela

Answer 1

These devices allowed the implementor(s) to avoid to define a new syscall or ioctl for the functionality, and maybe it was implemented that way because it was simpler, requires updating less code, and does not change the VFS API, which may have been the concerns at the time.

When you open /dev/autofs_nowait and traverse a path, you trigger auto-mounts, but don't wait for them to finish (otherwise your process blocks until the filesystem is mounted or after the operation times out), so you may receive a ENOENT when opening a file even if everything goes fine.

OTOH, /dev/autofs_notrigger makes the process not even trigger the auto-mounting.

That is all those devices do. The thing is that, in Darwin's implementation, open may block when traversing the filesystem even with O_NONBLOCK or O_NDELAY.

You can follow the flow from the vfs, from the open operation of a vnode:

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

Down that path there's no handling of the (non)blocking behavior.

Hondo

OK so if I understand correctly, the implementor(s) created both /dev/autofs_nowait and /dev/autofs_notrigger to essentially avoid having to add a new flag to e.g. fcntl() specifying autofs behavior?… Would you call that a correctly dumbed-down synopsis? – Danieldaniela

Not exactly, fcntl operates on an specific (already open) fd, while autofs_nowait affects every operation. Why it was implemented that way? maybe because it was simpler, requires updating less code, and does not change the VFS API, which may have been the concerns at the time. – Hondo

For some applications (interactive ones specially) it may make sense to block, except to the auto-mounter, and that's probably why it's used in CF. – Hondo

Thank you, @IsmaelLuceno, for amending the answer – this is all excellent information you have provided I must say. Is there any chance you could top it off with a solid citation link or two, where one could go for further reading on autofs and these /dev entries? That would truly take the cake, if I can say so. – Danieldaniela

Also, @IsmaelLuceno – in your view, would it appropriate to retag this question under autofs? – Danieldaniela

There's no much information about it but the code... the other interesting part is in the autofs kext... – Hondo

It would be interesting to investigate the history behind it. – Hondo

@Danieldaniela and yes, I find appropriate to re-tag it, though I can't create the tag, but I added xnu and vfs and removed the others since it seems less relevant. I'm not entirely sure if the bsd tag would apply, but I guess so, and the c tag could be removed... – Hondo

And I did it, IMO the c tag doesn't apply because we're discussing behavior, so code is secondary... – Hondo

Hey @IsmaelLuceno – I know this isn’t the most currently active question on SO but your example links into the VFS source code in the Darwin XNU repo have gone dead; no biggie really but if you should find yourself able to spare a moment enough to patch those up, I’d much appreciate it. Yes! – Danieldaniela

@Danieldaniela Fixed. – Hondo