Я смотрю на определенный клиентский код NFSv3 и пытаюсь справиться с несоответствием, которое возникает из-за реализации «автоматического c обхода вложенных точек монтирования». Для объяснения:
Сервер NFS (он же server) может иметь вложенные точки монтирования, скажем:
directory D1 is exported as /a
directory D2 is exported as /a/b
каждый объект файловой системы упоминается через full-path, например, server:/a/b/c/d/file.o
всякий раз, когда logi c имеет дело с каким-либо объектом, он находит самый длинный экспорт, который является подмножеством full-path, вызывает MNT, чтобы получить этот дескриптор точки монтирования, а затем все как обычно (цепочка LOOKUP с пока мы не получим ручку нашего объекта). Т.е. мы прозрачно перемещаемся из одной точки монтирования в другую по мере необходимости.
Несоответствие возникает при попытке перечисления (с использованием READDIRPLUS) server:/a - на сервере может отсутствовать объект b в каталоге D1. Или это может и не имеет ничего общего с D2 - использование GETATTR на server:/a/b приведет к совершенно другим атрибутам. К сожалению, некоторые логики c ожидают совпадения результатов READDIRPLUS и GETATTR.
Один из способов справиться с этим - перехватить все вызовы, которые возвращают метаданные (LOOKUP, READDIR[PLUS], MKDIR, CREATE, et c), проверьте параметры (и результаты) по списку экспорта и замените (или добавьте отсутствующие) данные результатами GETATTR вызовов, выполненных с использованием связанного дескриптора MNT. Выполнимо, но сложно и дорого. Кроме того, он полагается, что список экспорта не равен ie (на самом деле, некоторые NFS-серверы могут возвращать пустой список экспорта).
Как правильно решить эту проблему?
Linux NFS клиент справляется с проблемой и как?