Nano Hash - криптовалюты, майнинг, программирование

Определить фактически смонтированные тома и удаленные файловые системы в OSX

Мне нужно собрать список всех смонтированных «точек монтирования», к которым имеет доступ локальная файловая система.

Это включает в себя:

  • Любой обычно смонтированный том под /Volumes.
  • Любой том NFS, смонтированный в настоящее время под /net.
  • Любая локальная или удаленная файловая система, смонтированная с помощью команды «mount» или автоматически смонтированная каким-либо образом.

Но мне нужно избегать доступа к любым файловым системам, которые могут быть смонтированы автоматически, но в данный момент не смонтированы. Т. е. я не хочу вызывать никаких автоначислений.

Мой текущий метод выглядит следующим образом:

  1. Вызовите FSGetVolumeInfo() в цикле, чтобы собрать все известные тома. Это даст мне все локальные диски под /Volumes, а также /net, /home и монтирования NFS под /net.
  2. Вызовите FSGetVolumeParms(), чтобы получить «идентификатор устройства» каждого тома (это оказывается путем монтирования для сетевых томов).
  3. Если идентификатор представляет собой путь POSIX (т. е. он начинается с «/»), я использую readdir() в его родительском пути, чтобы проверить, действительно ли родительский каталог содержит элемент точки монтирования (например, если идентификатор равен /net/MyNetShare, то я читаю каталог /net). Если он недоступен, я предполагаю, что это точка автоматического монтирования с еще не смонтированным томом, и поэтому исключаю его из моего списка смонтированных томов.
  4. Наконец, если том кажется смонтированным, я проверяю, содержит ли он какие-либо элементы. Если да, то добавлю в свой список.

Шаг 3 необходим, чтобы увидеть, действительно ли путь смонтирован. Если вместо этого я вызову lstat() для полного пути, он попытается автоматически смонтировать файловую систему, чего мне следует избегать.

Теперь, несмотря на то, что вышеописанное работает большую часть времени, все еще есть некоторые проблемы:

  • Сочетание вызовов API-интерфейсов BSD и Carbon, а также специального оформления значения «идентификатор устройства» довольно нечисто.
  • Вызов FSGetVolumeInfo() дает мне точки монтирования, такие как "/net" и "/home", даже если они не кажутся реальными точками монтирования - точки монтирования скорее появляются внутри них. Например, если бы я смонтировал общий ресурс NFS в «/net/MyNFSVolume», я бы собрал как точку «/net», так и «/net/MyNFSVolume», но точка «/net» не является фактическим томом. .
  • Хуже всего то, что иногда описанный выше процесс по-прежнему вызывает активные попытки связаться с автономным сервером, что приводит к длительным тайм-аутам.

Итак, кто может показать мне лучший способ найти все фактически смонтированные тома?

macos filesystems unix
17.02.2015

Ответы:


1

Используя функцию уровня BSD getattrlist(), запрашивающую атрибут ATTR_DIR_MOUNTSTATUS, можно проверить флаг DIR_MNTSTATUS_TRIGGER.

Этот флаг, по-видимому, устанавливается только в том случае, если автоматически монтируемая точка общего доступа в настоящее время недоступна. Состояние этого флага, по-видимому, напрямую связано со статусом монтирования, поддерживаемым демоном automountd, который управляет повторным монтированием таких точек монтирования: пока automountd сообщает, что точка монтирования недоступна из-за того, что сервер не отвечает, установлен флаг «триггер».

Обратите внимание, однако, что этот статус не устанавливается сразу после того, как сетевая папка становится недоступной. Рассмотрим этот сценарий:

В файл /etc/auto_master добавлена ​​эта строка в конце:

/-                      auto_mymounts

Файл /etc/auto_mymounts имеет следующее содержимое:

/mymounts/MYSERVER1      -nfs,soft,bg,intr,net    myserver1:/

Это означает, что в /mymounts/MYSERVER1 будет каталог с автоматическим монтированием, предоставляющий доступ к корню экспортированного общего ресурса NFS myserver1.

Предположим, что сервер изначально доступен. Затем мы можем просмотреть каталог /mymounts/MYSERVER1, и флаг DIR_MNTSTATUS_TRIGGER будет очищен.

Затем давайте сделаем сервер недоступным, просто отключив сетевое соединение (например, отсоединив кабель Ethernet или отключив Wi-Fi). На этом этапе при попытке снова получить доступ к /mymounts/MYSERVER1 мы получим задержки и тайм-ауты, и мы можем даже получить кажущиеся действительными результаты, такие как непустые списки каталогов, несмотря на недоступный сервер. В этот момент флаг DIR_MNTSTATUS_TRIGGER останется очищенным.

Теперь переведите компьютер в спящий режим и снова разбудите его. В этот момент automountd снова пытается переподключить все автоматически монтируемые тома. Он заметит, что сервер отключен, и переведет точку монтирования в состояние «триггер». Теперь флаг DIR_MNTSTATUS_TRIGGER будет установлен по желанию.

Таким образом, хотя этот триггерный флаг не является идеальным индикатором, когда удаленный сервер недоступен, его достаточно, чтобы определить, когда сервер находится в автономном режиме в течение длительного времени, как это обычно происходит при перемещении клиентского компьютера между различными сетями, такими как как между работой и домом, при этом компьютер переводится в спящий режим между ними, в результате чего демон automountd обнаруживает доступность сервера NFS.

22.02.2015
Новые материалы
Кластеризация: более глубокий взгляд
Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
Как написать эффективное резюме
Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
Частный метод Python: улучшение инкапсуляции и безопасности
Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
Как я автоматизирую тестирование с помощью Jest
Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..