Кратко

  • RFC 3010 отделил постоянное имя клиента от текущего запуска: меняющийся после инициализации verifier, согласованный clientid и подтверждение с аутентификацией не позволяли одному имени автоматически наследовать прежние блокировки.
  • Потерявший состояние сервер открывал примерно на срок аренды grace period, принимал reclaims и удерживал новые конфликтующие блокировки и ввод-вывод. Непрерывность была процедурой с дедлайном, а не вечным правом.

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

RFC 3010, опубликованный в декабре 2000 года как первая полная спецификация NFSv4, сделал это противоречие частью протокола. Интегрированное блокирование означало, что серверное состояние требовало не только хранения, но и правил восстановления после расхождения памяти сторон.

Сначала различались клиент и его экземпляр. Клиент передавал устойчивый opaque id и verifier, который должен был меняться при каждой инициализации. Имя машины отвечало на вопрос «кто», но не «после какого запуска». Для летучей таблицы блокировок второй вопрос был решающим.

SETCLIENTID связывал пару с аутентифицированным RPC principal. Сервер возвращал короткий clientid и verifier подтверждения, а SETCLIENTID_CONFIRM замыкал обмен. clientid становился удобной локальной ссылкой на состояние. Он не был глобальной личностью, титулом собственности или переносимым полномочием.

Одинаковый opaque id мог появиться у двух машин из-за клонирования конфигурации или ошибки. NFS4ERR_CLID_INUSE делал столкновение явным. Совпадение имени не доказывало единого субъекта; иногда оно доказывало необходимость не смешивать их состояние.

Когда тот же аутентифицированный principal возвращался с новым verifier, сервер мог распознать новый экземпляр, утративший старую память, и освободить блокировки прежнего clientid. Без аутентификации это превратилось бы в атаку: посторонний мог бы изобразить чужую перезагрузку и снять действующие ограничения.

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

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

При перезапуске сервера асимметрия менялась местами. Клиенты сохраняли clientid и stateid, но новая эпоха сервера их не узнавала. NFS4ERR_STALE_CLIENTID и NFS4ERR_STALE_STATEID становились квитанцией о разрыве. Следовало получить новый clientid и перейти к восстановлению, а не продолжать обычные операции в старом пространстве.

Порядок задавал grace period. Примерно один lease прежние клиенты могли подавать LOCK и OPEN в форме reclaim, включая CLAIM_PREVIOUS. Простой безопасный сервер отвечал NFS4ERR_GRACE на новые locks, opens, reads и writes. Он уже работал, но временно не пользовался полномочием создавать новый конфликт.

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

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

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

RFC 2624 изложил исходные проектные задачи. RFC 3010 сменил RFC 3530, а RFC 7530 стал более поздней спецификацией NFSv4.0. Это история архитектуры, не нынешнее руководство по настройке.

В NFSv4.1 RFC 5661 добавил EXCHANGE_ID, сессии и более подробное восстановление. Заменивший его RFC 8881 показывает цену терпимости: чем больше reclaim сервер хочет признавать после сложных отказов, тем больше сведений о клиентах и состоянии должен хранить устойчиво.

Через призму Running-Code Primacy Лу Хэна действующее право возникает из проверок, которые новый сервер способен выполнить локально: principal, экземпляр, lease, форма reclaim, окно и отсутствие позднего конфликта. Минимальное общее правило не обещает вечную память; оно не позволяет новичку победить лишь потому, что авария сделала его первым.

Stability Fallacy возникает, когда неизменное имя или доступный экспорт принимают за непрерывность полномочий. RFC 3010 показал потерю как stale, задержал конфликты и потребовал пересобрать доказательства. Блокировка получила шанс не потому, что клиент её помнил, а потому, что протокол помнил порядок действий после забвения.

Sources