Кратко

  • Сообщая о завершении восстановления, клиент закрывает возможность позднее предъявить оставшиеся старые требования на блокировки в указанной области. За других клиентов такое сообщение ничего не решает.
  • Уже завершивший восстановление клиент всё ещё может получить ошибку периода восстановления при запросе новой блокировки.
  • Разрыв связи и последовательные перезапуски способны скрыть прекращение прежней защиты. Серверу нужна достаточная устойчивая история, чтобы распознать известные опасные случаи, иначе он обязан консервативно отказывать в восстановлении.

Два ответа на вопрос о готовности

Представим файловый сервер, на котором два клиента держали блокировки. Сервер перезапускается и теряет состояние блокировок. Первый клиент быстро возвращается, восстанавливает открытые файлы и блокировки диапазонов байтов. Второй остаётся недоступным из-за сетевого сбоя.

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

Это пример протокольной ситуации, а не описание измеренного инцидента. В разделах 8.4, 9.11 и 18.51 RFC 8881 разграничение выражено через конкретные операции NFSv4.1. Клиент способен успешно объявить о завершении восстановления и затем получить NFS4ERR_GRACE, запрашивая новую блокировку. Эти результаты не обязаны противоречить друг другу.

Старое требование не является новой заявкой

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

Для восстановления существующего открытого состояния применяется OPEN с CLAIM_PREVIOUS. Текущий файловый дескриптор протокола указывает целевой файл; операция не открывает новое имя из каталога. Для блокировки диапазона байтов используется LOCK с истинным параметром reclaim.

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

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

Завершение означает отказ от остатка

Глобальный вариант RECLAIM_COMPLETE передаёт ложное значение rca_one_fs. После создания нового идентификатора клиента такое сообщение необходимо до первого запроса новой блокировки. Правило действует и тогда, когда старых блокировок вообще нет. Пустой список нельзя просто оставить на усмотрение сервера.

Сообщение имеет последствия для ещё не восстановленных блокировок в своей области. Клиент больше не сможет предъявить их как старые требования — ни в этой процедуре, ни после следующего запуска сервера, ни после соответствующего переноса на другой сервер. Завершение закрывает оставшуюся возможность, а не только обновляет показатель готовности.

Именно поэтому сервер может использовать объявление как основание для решения. От этого клиента больше не должны поступать дополнительные старые требования из закрытой области. Однако определённость относится только к объявившему её участнику. Неопределённость в отношении остальных сохраняется.

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

Чтобы дождаться всех, нужно знать состав

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

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

Раздел 8.4.2.1 связывает её со сроком аренды состояния, или lease. Он рекомендует не завершать grace раньше этого срока, а при обсуждении изменения значения требует интервал не короче срока предыдущего экземпляра сервера. Эти условия нельзя заменить выдуманным единым числом секунд для всех установок. Они сохраняют связь с обстоятельствами, на которые клиенты опирались до сбоя.

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

Свободная блокировка может иметь небезопасную историю

Самый трудный случай возникает, когда представление клиента о непрерывной защите переживает реальное прекращение этой защиты.

RFC описывает разделение сети, из-за которого клиент не продлевает lease. Срок истекает, сервер освобождает блокировку. Другой клиент получает блокировку, которая конфликтовала бы с прежней, выполняет работу и освобождает её. Затем сервер перезапускается. Связь восстанавливается, и первый клиент приходит в новом периоде grace за своей старой блокировкой.

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

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

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

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

Прикладная работа остаётся отдельной задачей

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

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

Официальная карточка документа указывает для RFC 8881 статус Proposed Standard, дату август 2020 года и замену RFC 5661. В проверенном списке исправлений подтверждённые поправки отделены от только заявленных предложений. Прямого изменения трёх центральных разделов в полученном списке нет. Это не доказывает безошибочность всего документа и не является проверкой соответствия современных продуктов.

Заметка 32 Lu Heng о проблеме агентских отношений предлагает рассматривать связь полномочий с ответственностью за последствия. Заметка 36 о реальности, а не продвижении позиции задаёт требование описывать устройство системы без выдуманного морального конфликта. Здесь это редакционная перспектива. Технические правила подтверждает RFC, а не предположения о мотивах конкретного поставщика.