14

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:

    dev directory listing

    … 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.

fish2000
  • 4,289
  • 2
  • 37
  • 76

1 Answers1

4

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:

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

Ismael Luceno
  • 2,055
  • 15
  • 26
  • 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? – fish2000 Sep 22 '16 at 00:09
  • 1
    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. – Ismael Luceno Sep 22 '16 at 03:57
  • 1
    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. – Ismael Luceno Sep 22 '16 at 04:10
  • 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. – fish2000 Sep 22 '16 at 08:18
  • Also, @IsmaelLuceno – in your view, would it appropriate to retag this question under `autofs`? – fish2000 Sep 22 '16 at 08:21
  • 1
    There's no much information about it but the code... the other interesting part is in the autofs kext... – Ismael Luceno Sep 22 '16 at 12:25
  • It would be interesting to investigate the history behind it. – Ismael Luceno Sep 22 '16 at 12:27
  • @fish2000 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... – Ismael Luceno Sep 22 '16 at 12:43
  • And I did it, IMO the c tag doesn't apply because we're discussing behavior, so code is secondary... – Ismael Luceno Sep 22 '16 at 12:50
  • 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! – fish2000 Feb 23 '19 at 17:37
  • 1
    @fish2000 Fixed. – Ismael Luceno Mar 16 '19 at 00:29