Каталоги появляются как псевдонимы объема

Q: Я пишу сетевую файловую систему (плагин VFS KEXT) для Mac OS X. Все, кажется, хорошо работает на уровне BSD, но Средство поиска является очень запутанным, показывая каждый каталог в моей файловой системе как псевдоним объема. Как я могу фиксировать это?

A: Я пишу сетевую файловую систему (плагин VFS KEXT) для Mac OS X. Все, кажется, хорошо работает на уровне BSD, но Средство поиска является очень запутанным, показывая каждый каталог в моей файловой системе как псевдоним объема. Как я могу фиксировать это?

Для решения этой проблемы, необходимо гарантировать, что каждый объект на объеме возвращает то же значение в st_dev поле, возвращенное stat. Кроме того, это значение должно соответствовать номер устройства для самого объема. Система получает номер устройства для объема путем вызова statfs и извлечение номера устройства от первого слова f_fsid массив в statfs структура. Необходимо удостовериться, что это число соответствует значение, из которого Вы возвращаетесь stat.

Типичный поток данных для этого значения следующие.

• Для локальной файловой системы, Ваша точка входа монтирования (examplefs_mount) вызывается с параметрами, содержащими путь к узлу устройства. Ваша файловая система должна искать этот путь (использование namei) найти vnode для устройства (позволяют нам вызвать это devvp). Это должно тогда инициализировать объем f_fsid следующим образом.

  mp->mnt_stat.f_fsid.val[0] = (long) devvp->v_rdev; mp->mnt_stat.f_fsid.val[1] = mp->mnt_vfc->vfc_typenum;

• Для сетевой файловой системы, Ваша точка входа монтирования (examplefs_mount) должен инициализировать объем f_fsid путем вызова vfs_getnewfsid. Это устанавливает f_fsid к синтетическому значению, однозначно определяющему объем.

• В Вашем statfs точка входа (examplefs_statfs), удостоверьтесь, что Вы возвращаете разумные результаты в f_fsid поле statfs структура. В большинстве случаев Вы ничего не должны делать здесь, потому что система получает начальное значение этой структуры от Вашего объема mnt_stat структура.

• В Вашей getattr точке входа (examplefs_getattr), возвратите номер устройства (mp->mnt_stat.f_fsid.val[0]) в vap->va_fsid так, чтобы ядро могло скопировать то значение в st_dev поле stat структура, которую это возвращает вызывающей стороне.

• Если Ваш объем поддерживает ATTR_CMN_DEVID атрибут (см. Технические Вопросы и ответы QA1327, 'Документация для getattrlist' для подробных данных), его значение должен соответствовать st_dev значение возвратилось через stat.

• Если Ваш объем поддерживает ATTR_CMN_FSID атрибут, его значение должно соответствовать f_fsid значение возвратилось через statfs.

Остальная часть этого документа объясняет, как спутывание Ваших номеров устройств приводит к наблюдаемым признакам. Если все, что Вы хотите сделать, решают эту проблему и движение к следующей ошибке, можно безопасно пропустить его. С другой стороны, если Вы хотите узнать немного о взаимодействии между Файловым менеджером Углерода и уровнем BSD Mac OS X, любой ценой продолжайте читать.

Для понимания, что идет, необходимо понять различие между тем, как BSD и Углерод представляют файловую систему в целом. Под BSD файловая система является единственным деревом. Каждый объем смонтирован, поскольку каталог в дереве (точка монтирования) и перемещающийся через тот каталог может взять Вас от одного объема до другого. Программы BSD знают об этом и могут справиться с ним очень хорошо.

С другой стороны, Углерод представляет файловую систему как лес деревьев. Каждый объем имеет свой собственный корневой каталог с деревом каталогов, распространенных под ним. Поскольку каждый объем является отдельным объектом, программы Углерода не ожидают, что перемещение в структуре каталогов объема возьмет их к различному объему.

Mac OS X должен обеспечить семантику BSD для программ BSD и семантику Углерода для программ Углерода. Семантика BSD является собственной семантикой файловой системы на Mac OS X, так, чтобы часть была проста. Обеспечение семантики Углерода более хитро. Файловый менеджер углерода ответственен за эмуляцию семантики Углерода поверх собственного BSD API. Это включает много тонких приемов, некоторые из которых могут сбить с толку лица, осуществляющие внедрение файловой системы. Таким образом это - всего один пример общей проблемы: необходимо тщательно кодировать плагин VFS для программ Углерода для работы должным образом.

Этот особый случай вращается вокруг точек монтирования. Когда Файловый менеджер Углерода встречается с точкой монтирования в каталоге, он не может передать точку монтирования непосредственно назад программе, потому что программы Углерода не ожидают пересекать объемы при навигации по дереву каталогов. Вместо этого Файловый менеджер Углерода возвращает то, что известно как синтетический псевдоним. К программе Углерода этот синтетический псевдоним похож на файл псевдонима ( kIsAlias бит установлен во флагах Средства поиска файла). Если программа Углерода хочет пересечь этот 'псевдоним', она вызывает менеджера по Псевдониму для разрешения его. Менеджер по Псевдониму распознает синтетический псевдоним и разрешает его путем возврата ссылки на корневой каталог целевого объема. Таким образом, к программе Углерода, точка монтирования похожа на псевдоним к корневому каталогу целевого объема.

В этом случае Файловый менеджер Углерода интерпретирует каждый каталог в Вашей файловой системе как точка монтирования, и таким образом программы Углерода (включая Средство поиска) рассматривают каждый каталог как псевдоним к объему. Ключевой вопрос состоит в том почему. Оказывается, что Файловый менеджер Углерода использует номер устройства, связанный с объектом файловой системы ( st_dev поле stat структура, возвращенная stat) определить изменения точки монтирования. При исследовании каталога Файловый менеджер Углерода выдерживает сравнение st_dev из каталога с номером устройства, связанным с объемом, на котором находится каталог. Если они отличаются, как имеет место с Вашей файловой системой, она предполагает, что каталог представляет точку монтирования. В той точке это возвращает синтетический псевдоним для объема, который Средство поиска выводит на экран как псевдоним объема. При создании всего соответствия номеров устройств (как описано выше), Файловый менеджер Углерода распознает каталоги как каталоги, и проблема уходит.

История версии документа