Кратко

  • RFC 1094 отделяет имя в каталоге от локальной открытой ссылки на файл: сервер NFSv2 без состояния протокола не знал, что удалённый процесс ещё использует файл, и не мог сам гарантировать такое поведение.
  • В качестве обхода документ называет переименование при удалении и последующую очистку после закрытия. Он не задаёт общего формата временного имени и не определяет восстановление после сбоя клиента.

Предел гарантии проходит там, где кончаются сведения сервера

Пользователь убрал файл из каталога, но процесс всё ещё читает его. Для локальной файловой системы это могут быть совместимые факты: имя уже исчезло, а открытая ссылка процесса действует до закрытия. В сетевом варианте вопрос меняется: кто из двух узлов знает, что именно ещё происходит?

Операционная система клиента знает процесс и его локальное открытие. Клиент NFS преобразует часть действий в сетевые запросы. Сервер управляет экспортируемым каталогом и исполняет полученные операции. Если сервер получил удаление имени, он не узнаёт автоматически, что процесс на другом компьютере ещё рассчитывает на этот объект.

RFC 1094, опубликованная в марте 1989 года спецификация NFS версии 2, прямо указывает на это ограничение: сервер без состояния протокола не способен сам воспроизвести семантику, при которой файл остаётся доступен после удаления его имени. Текст предлагает перенести адаптацию к клиенту: переименовать запись, а окончательно удалить её после локального закрытия.

Это ограниченное утверждение о распределении сведений. RFC не обещает, что любой клиент реализует обход одинаково, и не трактует отсутствие такой гарантии как отказ всей файловой системы. Она показывает, что серверу недостаёт факта о локальном процессе.

Идентификатор объекта не сообщает, кто его открыл

В NFSv2 есть процедуры LOOKUP, READ, WRITE, CREATE, REMOVE и RENAME. REMOVE получает ссылку на каталог и имя. Удалённых процедур OPEN и CLOSE, которые создавали бы на сервере запись об открытии конкретным клиентом и сообщали о последнем закрытии, в этом интерфейсе нет.

Файловые операции используют дескриптор объекта, выданный сервером. Он позволяет адресовать объект, но не содержит счётчика локальных процессов и не доказывает, что приложение вызвало open(). Ядро клиента может обработать открытие локально, а сервер позднее получит REMOVE, не зная, что процесс ещё держит ссылку.

Отсюда следует, почему нельзя подменить открытое состояние самим файловым дескриптором. Первый нужен для обращения к объекту; второе описывает связь объекта с локальными процессами во времени. RFC 1094 не запрещает клиенту воспроизводить нужное поведение, но сервер без дополнительного сведения не может решить эту задачу один.

Переименование меняет момент удаления записи

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

Так расходятся два события: исчезновение имени и окончательное удаление удалённой записи. Одна команда, воспринимаемая приложением как удаление, включает решение клиента, действие сервера и отложенную очистку. У сервера остаётся работа, хотя пользователь уже не видит прежнее имя.

RFC не указывает формат временного имени, правила против коллизий, поведение нескольких клиентов или восстановление, если клиент перезагрузился до закрытия. Она не является спецификацией распределённой транзакции и не описывает детали конкретного продукта.

Можно заключить, что отложенная очистка способна зависнуть или завершиться ошибкой; это возможность, вытекающая из последовательности действий, а не измеренный в RFC показатель. Для утверждения о конкретной реализации нужны её код, руководство или результаты испытаний.

«Без состояния» относилось к протокольному диалогу

Задача состояла в том, чтобы серверу не приходилось хранить для каждого клиента протокольное состояние открытых файлов. После прерывания клиент мог повторять операции, не восстанавливая целую удалённую сессию открытий. При этом содержимое файлов, атрибуты и каталог оставались состоянием файловой системы и хранилища.

Локальная открытая ссылка принадлежит отношениям между процессом и операционной системой клиента. По последовательности запросов NFSv2 сервер не мог установить её срок жизни. Блокировки файлов и записей RFC 1094 тоже относила к отдельным службам. Протокол определял, что именно стороны должны координировать по сети.

В NFSv3 набор процедур также не включает удалённые OPEN и CLOSE. В RFC 7530 для NFSv4 такие операции и stateid уже есть. Это не доказывает, что все установки перешли на новую версию или одинаково трактуют открытие. Это показывает иной выбор: включить состояние открытия в протокольную координацию и принять связанные с ней издержки.

Исполнять операцию и знать её контекст — разные роли

Сервер распоряжается экспортируемым каталогом и исполняет REMOVE. Клиентская ОС знает, какие процессы держат открытие. Пока эта связь не сообщается удалённой стороне, сервер не может сам выбрать безопасный момент окончательного удаления. Временное переименование использует знания клиента, но требует от него учёта и очистки.

Владелец приложения должен подтвердить, действительно ли ему нужен доступ после исчезновения имени. Реализация клиента должна объяснить, как хранится временное имя и что происходит при перезапуске. Оператор сервера должен уметь отличить удалённое имя от ещё существующей записи. RFC не устанавливает для этих ролей политику эксплуатации.

Возможны три решения: использовать проверенный обход на клиенте; изменить приложение так, чтобы оно закрывало файл перед удалением имени; либо испытать более позднюю версию протокола и реализацию на требуемом сценарии. Выбор меняет расположение сложности. Сам факт успешного монтирования не подтверждает все локальные файловые гарантии.

Следствие второго порядка — видимость каталога может не совпадать с освобождением хранилища. На третьем уровне отчёты резервного копирования, квот, хранения и расследования инцидентов могут расходиться, если наблюдают разные слои. Необратимый риск — удалить данные, которые ещё нужны процессу; противоположный риск — оставить бесхозную временную запись. RFC 1094 обозначает семантическую границу, но политика восстановления и хранения остаётся задачей работающей системы.

Источники и границы свидетельств

Документы подтверждают спецификацию и проектные рассуждения. Они не показывают распространённость переименования, порядок очистки в конкретном клиенте после аварии или частоту таких случаев в эксплуатации.