Кратко

  • fattr4_uncacheable_file_data передаёт желаемый режим со стороны сервера, а не показание датчика внутри клиента.
  • Для уже открытого файла изменение значения и переход клиента к новому поведению могут происходить в разное время.
  • Проверяемое утверждение требует двух связанных следов: серверной политики и клиентских фактов о revalidation, COMMIT и write verifier.

Между командой и состоянием есть протокол

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

Проект draft-ietf-nfsv4-uncacheable-files-13 даёт серверу недостающее слово — логический атрибут для отдельного файла. Администратор сможет сообщить, что обычная политика кэширования здесь нежелательна. Однако в панели управления это сообщение легко превратить в результат: истинное значение показать как «кэш клиента очищен».

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

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

Возможность принадлежит экспорту, а не марке сервера

Атрибут 87 доступен для чтения и записи и помещён в категорию RECOMMENDED таблицы атрибутов NFS. Здесь это название категории, а не отдельное требование к каждому серверу NFSv4.2. Поддержка может различаться у двух файловых систем, экспортируемых одной машиной. Успешная проверка одного тома не доказывает возможность другого.

Смысл ограничен и типом объекта. Атрибут относится к обычным файлам и именованным атрибутам. Для иных типов GETATTR возвращает ложь, а SETATTR завершается ошибкой. Поэтому одна ложь не различает разрешённый обычный кэш, неприменимый тип и отсутствие поддержки. В доказательстве должны оставаться тип, множество поддерживаемых атрибутов и значение.

Третье измерение — полномочия. Сервер может разрешать изменения, всегда отклонять их согласно политике или вычислять значение из локального правила, например отмечать новые файлы под определённой точкой монтирования. Обычная авторизация сохраняется. История должна показывать источник правила, уполномоченного субъекта и отклонённые попытки, а не только последнее логическое значение.

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

Для записи важна граница возврата в приложение

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

К этому можно прийти стабильной записью. Можно также отправить нестабильную запись и завершить COMMIT до возврата успеха. Если write verifier сервера изменился, затронутые WRITEs требуется повторить из данных, которые клиент всё ещё хранит. Временное удержание байтов ради незавершённой операции проект не считает запрещённым кэшем.

Измерение «ноль байтов в памяти» способно объявить неправильным именно корректный клиент, которому нужны данные для повтора. Полезная квитанция хранит запрошенный и полученный режим стабильности, результат COMMIT, прежний и новый verifier, повторные передачи и момент успешного возврата приложению. Только такая последовательность помогает после сбоя проверить судьбу конкретной подтверждённой записи.

Серверный атрибут направляет эту последовательность, но не подтверждает ни одного из её событий.

Для чтения важна причина доверять данным

В части чтения проект не требует ритуально уничтожать каждую локальную копию. Клиенту предлагается не использовать кэшированные данные без перепроверки. Минимальный набор — change attribute NFS и размер файла; реализация может сверять дополнительные свойства.

Это продолжает модель согласованности NFSv4.1. Валидность кэша координируется с OPEN, share reservations, блокировками и делегированием. Делегирование может обеспечивать клиенту согласованное представление, при котором хранение данных для чтения остаётся разумным даже при истинном новом атрибуте.

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

Серверная запись рядом с клиентской квитанцией

Серверная запись отвечает на узкий вопрос: какой режим этот сервер объявил для этого файла в данный момент? В ней нужны идентичность сервера и экспортированной файловой системы, поддержка атрибута 87, файл, значение, источник политики, полномочия и время наблюдения.

Клиентская квитанция отвечает, что сделал с объявлением конкретный клиент. Она указывает реализацию и версию, монтирование, file handle, эпоху открытия, время получения значения и наличие прежнего OPEN. Для чтения добавляются change, размер, делегирование и действие с кэшем. Для записи — стабильность, COMMIT, verifier, повтор и возврат в приложение.

Записи связываются файлом и операцией, но не переписывают друг друга. Если сервер меняет значение в 16:00, а клиент с открытым файлом видит его в 16:11, нужны обе отметки. Одна «дата действия» уничтожает сведения о распространении и делает старую сессию неотличимой от новой.

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

Добровольное внедрение надо показывать слоями

RFC 8178 задаёт способ расширять NFSv4.2, не отменяя базовую спецификацию RFC 7862. Новая возможность необязательна, а клиент сохраняет выбор реализации в пределах заданных инвариантов. Следовательно, отчёт о парке должен показывать распределение способностей, а не выдавать последнюю семантику за всеобщую.

Практические состояния таковы: экспорт не поддерживает атрибут; поддерживает, но значение ложно; значение истинно, но клиент ещё не увидел его; клиент применяет его к новым операциям; для операции существует проверенная квитанция. Эта лестница отделяет потребность в обновлении от пробела наблюдаемости.

В разделе о реализации описаны прототип сервера Hammerspace и клиент Linux с поведением, похожим на direct I/O, для файлов под настроенной точкой монтирования. Сообщённые выгоды по производительности, памяти и процессору на подходящих нагрузках подтверждают осуществимость. Они не обещают одинаковую архитектуру или результат для всех клиентов. «Похоже» не означает «тождественно», а один прототип не является стандартом неоднородного парка.

Атрибут нельзя превратить в границу безопасности

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

Вместо большого обещания можно делать узкие проверяемые утверждения. Сервер запросил ограничение кэша. Измеряемый клиент позже увидел запрос. Конкретное чтение было перепроверено. Конкретная запись стала устойчивой до успешного возврата. У каждой фразы свой источник, и первая не порождает остальные автоматически.

Ценность предложения от этого не уменьшается. Протокол получает стандартное поле для серверного намерения. Клиентская квитанция показывает, где это намерение превратилось в поведение, где задержалось и по какой причине.

Источники