Риски и выгоды от использования /dev / autofs nowait на OS X

На всем протяжении исходного кода CoreFoundation framework , вызовы API файловой системы POSIX (напр.open(), stat(), et al ... ) являются обернутыми в идиому, в которой дескриптор на /dev/autofs_nowait приобретается – с open(…, 0) – перед вызовами POSIX; после этого дескриптор close()’d Перед выходом из области.

  • Какая от этого польза? Каковы риски?

  • Имеет ли получение дескриптора /dev/autofs_nowait какое-либо влияние на, или это осуществляется с помощью флагов для любых обернутых таким образом open() вызовов (например, O_NONBLOCK)?

  • /dev на моей машине под управлением OS X 10.10.5 есть другие записи "autofs":

    список каталогов dev

    ... ни одна из которых не имеет доступных страниц man. Если эти файлоподобные устройства могут предложить преимущества в этом отношении, мне было бы интересно услышать об их использовании, поскольку это может иметь отношение.


Добавление: я не смог найти много на эта тема; сообщение Google Plus от 2011 года утверждает, что:

[t]его файл-это специальное устройство, которое отслеживается автографами. реализация файловой системы в ядре. При открытии автографы файловая система не заблокирует этот процесс ни при каких операциях ввода-вывода на файловая система autofs.

Я не совсем уверен, что это означает (они специально говорили о том, как launchd работает, FWIW), но мне самому было любопытно об этом, поэтому я написал быстрый context-manager-y RAII struct to try it out – нецелевое профилирование показывает тесты с вызовами POSIX, завершающимися быстрее, но в пределах общих хэш-меток; я исследую эту тактику с более тонкой зубчатой гребенкой после того, как получу больше информации о том, как все это работает.

1 13
asynchronous vfs core-foundation bsd

1 ответ:

Эти устройства позволили разработчику(ам) избежать определения нового syscall или ioctl для функциональности, и, возможно, это было реализовано таким образом, потому что это было проще, требует обновления меньшего количества кода и не изменяет API VFS, что, возможно, было проблемой в то время.

Когда вы открываете /dev/autofs_nowait и проходите путь, вы запускаете автоматическое монтирование, но не ждете его завершения (в противном случае ваш процесс блокируется до тех пор, пока файловая система не будет смонтирована или после истечения времени ожидания операции), поэтому вы можете получить ENOENT при открытии файла, даже если все идет нормально.

OTOH, /dev/autofs_notrigger делает процесс даже не инициировать автоматическое монтирование.

Это все, что делают эти устройства. Дело в том, что в реализации Дарвина open может блокировать при обходе файловой системы даже с O_NONBLOCK или O_NDELAY.

Вы можете следить за потоком из vfs, из open операции vnode:

На этом пути нет обработки (не)блокирующего поведения.

4