Кратко

  • Операция LAYOUT_WCC переносит на сервер метаданных атрибуты после операции, уже полученные клиентом от сервера данных по NFSv3.
  • Сервер может использовать их вместо GETATTR, проигнорировать или запросить состояние напрямую; в ответе нет перечня принятых атрибутов.
  • Отчёт о размере, времени и владельце не доказывает устойчивость байтов, равенство зеркал, корректность доступа или результат приложения.

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

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

Разделение нагрузки разделило знание

В pNFS есть плоскость метаданных и плоскость данных. Сервер метаданных управляет пространством имён, выдаёт и отзывает layouts и способен обслуживать ввод-вывод сам. Но layout может направить клиент к серверам данных. Flexible file layout разрешает этим серверам использовать уже существующие версии NFS, в том числе NFSv3.

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

Прямой GETATTR устраняет неопределённость: сервер метаданных получает текущие значения размера, используемого места и времени. Однако это отдельная операция и отдельная нагрузка на уровень хранения. При большом потоке запросов проверка может стать заметной стоимостью. Более того, WRITE и последующий GETATTR в NFSv3 требуют двух обменов, тогда как составная операция NFSv4 может вернуть результат и атрибуты совместно.

RFC 9766 добавляет в NFSv4.2 операцию 77 — LAYOUT_WCC. Ответы NFSv3 на READ, WRITE и COMMIT могут содержать Weak Cache Consistency. Клиент сопоставляет эти данные с атрибутами NFSv4.2 и отправляет их серверу метаданных.

Слабость задаёт предел вывода

WCC в RFC 1813 сочетает отдельные атрибуты до операции и атрибуты после неё. Сопоставление помогает клиенту заметить возможное постороннее изменение и решить, следует ли сбросить кеш. Это уже не одиночный снимок, а короткий интервал наблюдения.

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

RFC 9766 не маскирует это ограничение. Сервер метаданных вправе счесть отчёт достаточно свежим и отказаться от повторной проверки. Он вправе выполнить GETATTR, если данные устарели, расходятся или влияют на решение с высокими последствиями. Единым становится формат сообщения, а не политика доверия.

Свобода есть у обеих сторон. Клиент может не использовать полученную информацию WCC. Сервер может отбросить атрибуты из LAYOUT_WCC. Поскольку клиенту нечего исправлять при таком решении сервера, результат не содержит bitmap принятых полей. Успех операции не означает, что каждый переданный атрибут стал авторитетным состоянием.

Восемь полей дают контекст, а не вердикт

Для flexible file layout определено восемь соответствий: size, space_used, mode, owner, owner_group, time_access, time_modify и time_metadata. Числовые uid и gid преобразуются в строковые значения владельца и группы, принятые в NFSv4.

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

В RFC перечислены моменты, когда отчёт может быть полезен. Клиент может послать его перед запросом размера, занятого пространства, change attribute или времени. Он может приложить наблюдавшиеся uid/gid к сообщению о NFS4ERR_ACCESS. При подходящей делегации можно использовать отчёт при обновлении времени доступа и изменения.

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

Номер в массиве не идентифицирует файл

Текущий filehandle и lowa_stateid связывают отчёт с layout, а lowa_type определяет трактовку непрозрачной нагрузки. В flexible file layout она может описывать зеркала и входящие в них серверы данных.

Позиции этих массивов не являются устойчивыми именами. При трёх зеркалах клиент может перечислить все и оставить пустую маску у неизменённого. Он также может прислать только два изменившихся. Во втором случае «второй элемент» обозначит другой объект. Файл данных следует узнавать по сочетанию device ID, stateid и filehandle. Все три поля необходимы: один storage device способен содержать несколько файлов одного layout.

Это частный случай общего правила доказательности: соседство не равно тождеству. Квитанция, рассчитанная на неполные выборки и перестановки, должна именовать объект устойчивыми полями.

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

Один зелёный сигнал не покрывает соседние слои

Атрибуты описывают наблюдавшееся состояние. Устойчивая запись байтов доказывается отдельно. Если запись не вернула FILE_SYNC, flexible file layout требует сделать нестабильные записи устойчивыми через COMMIT до LAYOUTCOMMIT. LAYOUT_WCC не сокращает эту последовательность.

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

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

Необязательность оставляет рабочую альтернативу

Операция необязательна для NFSv4.2 и для flexible file layout. Клиент или сервер без операции 77 продолжает взаимодействовать по прежним путям, включая прямую проверку. Возможно, он выполнит больше работы, но отсутствие оптимизации само по себе не означает неисправность.

RFC 8178 задаёт правила расширения NFSv4, а RFC 7862 и RFC 7863 дают основу протокола и XDR для NFSv4.2. Они подтверждают синтаксис и нормативный статус операции. Только работающие endpoints подтверждают, что поддержку согласовали и операцию действительно использовали.

Модель безопасности унаследована от flexible file layout. Loose coupling может применять синтетические uid/gid для ограничения сотрудничающих клиентов, но не обязательно защищает от злонамеренного клиента и не всегда способен изолировать одного участника. Tight coupling зависит от своего протокола управления. Фоновые соединения нужно защищать от чтения и подмены. Аутентификация устанавливает отправителя отчёта в этом канале, но не доказывает, что каждое значение остаётся самым новым на сервере данных.

Источники

  1. RFC 9766: Extensions for Weak Cache Consistency in NFSv4.2's Flexible File Layout
  2. RFC 8435: Parallel NFS Flexible File Layout
  3. RFC 8434: Requirements for pNFS Layout Types
  4. RFC 1813: NFS Version 3 Protocol
  5. RFC 8881: NFS Version 4 Minor Version 1 Protocol
  6. RFC 7862: NFS Version 4 Minor Version 2 Protocol
  7. RFC 7863: NFSv4.2 XDR Description
  8. RFC 8178: Rules for NFSv4 Extensions and Minor Versions
  9. RFC 9754: Extensions for Opening and Delegating Files in NFSv4.2
  10. Running-Code Primacy
  11. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  12. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile