Кратко

  • Во время recovery grace period RFC 9737 разрешает клиенту передать через LAYOUTRETURN ошибку I/O с анонимным нулевым stateid, хотя прежний layout stateid уже недействителен.
  • Reclaim без ошибок, явная ошибка, отсутствие клиента и устаревший mirror set — разные свидетельства и приводят к разным основаниям для resilvering.
  • Нулевой идентификатор допускает показание, но не доказывает целостность данных, правильность выбранного источника или успех последующей реконструкции.

После перезапуска MDS два файла показывали ноль ошибок. Первый клиент вернулся, восстановил open state и не сообщил о сбое. Второй клиент не появился вовсе.

Если смотреть только на счётчик, файлы одинаковы. Если смотреть на доказательства, один имеет отрицательное наблюдение, а второй не имеет свидетеля.

RFC 9737 построен вокруг этой разницы. Он не пытается сделать восстановление оптимистичным. Он позволяет уменьшить лишний resilvering только там, где клиент реально участвовал в recovery и мог донести наблюдение, сделанное во время отсутствия metadata server.

Старое полномочие исчезло, наблюдение осталось

В pNFS flexible file layout MDS выдаёт layout, а клиент обращается к data servers напрямую. При client-side mirroring клиент обновляет все копии. Поэтому именно он первым знает, что WRITE на одном mirror завершилась ошибкой.

Структура ff_ioerr4 из RFC 8435 содержит device, operation, status, offset и length. Спецификация называет такие сообщения hints для MDS. Это структурированное свидетельство о конкретной операции, а не полная проверка каждого байта.

После restart прежние layout stateids недействительны. Grace period позволяет reclaim открытого состояния через CLAIM_PREVIOUS, но клиент не может получить новый layout лишь для того, чтобы рассказать об ошибке старого периода.

RFC 9737 требует принять в LAYOUTRETURN all-zero anonymous stateid. Он не оживляет layout и не разрешает обычный I/O. Он открывает узкий канал для отчёта.

Нулевое значение связано со временем

Внутри grace другой stateid получает NFS4ERR_GRACE. После grace нулевой stateid получает NFS4ERR_NO_GRACE. При ответе на анонимную форму MDS не должен увеличивать seqid result stateid.

Таким образом, историческое наблюдение участвует в recovery, но не изображает обычный переход живого layout state. Для аудита нужны restart epoch, границы grace, client, file, write intent, mirror set, поля ошибки, ответ и решение. Отдельная запись stateid=0 ничего не доказывает.

Узость правила важнее удобства. Один идентификатор, одна операция, одно окно и одна цель не дают исключению превратиться в постоянный обход authority.

Три нуля в метрике — три разных состояния

Если клиент reclaim-ит файл и не сообщает ошибку, MDS не должен resilver. Если клиент сообщает ошибку, файл должен быть resilvered. Если до конца grace нет ни reclaim, ни отчёта, MDS тоже обязан перестроить файл: клиент мог перезапуститься и потерять локальное состояние.

Явная ошибка — положительное свидетельство проблемы. Молчание отсутствующего клиента — нехватка свидетельства. Пустой отчёт после reclaim — ограниченное отрицательное свидетельство. Свести их к error_count=0/1 означает уничтожить политику принятия решения.

Даже clean reclaim не является побайтовым proof. Он подтверждает, что этот клиент не наблюдал и не передал ошибку по определённому пути. Silent corruption, другой client и логика приложения остаются за пределами такого receipt.

Устаревшая правда не управляет текущим набором зеркал

MDS сравнивает layout из отчёта с текущими mirror instances. При несовпадении он должен игнорировать LAYOUTRETURN и resilver файл. Клиент может быть точен относительно старого набора, но эта точность не связывает новый набор.

Нужно хранить fingerprint того, что видел клиент, и fingerprint текущего набора MDS. Без результата сравнения запись «error received» не говорит, применил ли сервер отчёт или выбрал консервативный путь из-за stale topology.

Идентичность набора зеркал является частью доказательства. Совпавшее имя device не заменяет совпадение membership и recovery epoch.

Resilvering имеет собственные предпосылки

Write intent возникает вместе с LAYOUTIOMODE4_RW. MDS должен отслеживать outstanding intents через restart. Порядок восстановления включает fencing файла, запись необходимости ремонта, освобождение write intent и запуск копирования только после исчезновения всех intents. Пока остаётся полномочие записи, resilver начинать нельзя.

Во время копии MDS может блокировать I/O, направлять его через себя или вставить proxy. Это локальный выбор. Если доступ продолжается, клиент должен видеть прежний layout set, а proxy обязан оставаться до конца grace.

Принятый report не подтверждает выполнение этих шагов. Нужны отдельные receipts: источник читается, ranges скопированы, mirrors сошлись, последующий read вернул ожидаемые данные, приложение их приняло.

Старая версия честно выбирает дорогой путь

MDS без расширения может вернуть NFS4ERR_BAD_STATEID. Клиент должен перейти к старому поведению и не передавать ошибку этим способом. Это честная несовместимость: сервер не изображает понимание.

Цена — консервативный resilvering. Система тратит bandwidth, IOPS и время вместо выдуманной уверенности. Метрики должны показывать fallback отдельно от успешного приёма RFC 9737.

Операционная проверка здесь означает проверять пару, а не паспорт каждой стороны: попытку, response, fallback, topology match, решение, write-intent ordering и фактический результат.

Нулевой stateid полезен не потому, что даёт широкое право. Он полезен потому, что точно отделяет право быть услышанным от права действовать и от доказательства результата.

Источники