Кратко

  • Редакция от 26 сентября остаётся действующим Internet-Draft рабочей группы NFSv4 со статусом I-D Exists, а не опубликованным RFC.
  • Новый раздел о pNFS уточняет: клиент может выполнить READDIR заново и всё равно получить прежние атрибуты файла, если сервер метаданных ещё не узнал о записи через LAYOUTCOMMIT.

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

Базовый механизм был и в предыдущей, одиннадцатой редакции от 5 сентября. Новая редакция уточнила, что формального запроса к серверу недостаточно. Если отправить READDIR почти без запрошенных атрибутов, а размер и время взять из старой памяти клиента, требование теряет смысл. Нужные сведения следует запросить в READDIR либо получить позже. Второй путь может потребовать отдельного GETATTR для каждого элемента. Флаг ограничивает отображение метаданных записей каталога; он не запрещает кэшировать данные самого файла и не вводит общее правило для всех каталогов монтирования.

Главное дополнение помещено в разделе 5.2. В параллельном NFS каталог и его флаг относятся к серверу метаданных, тогда как сами данные могут записываться на отдельное устройство хранения. Для схемы, в которой новый размер и time_modify становятся известны серверу метаданных только после LAYOUTCOMMIT, запрос READDIR до этого момента вернёт прежние значения. Клиент, передающий именно эти значения, может полностью выполнять проектируемое правило. Источник задержки уже не в его собственном кэше: сведения ещё находятся на другой стороне границы между устройством данных и сервером метаданных.

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

Редакция 12 уточняет и административную сторону. Сервер вправе по локальной политике отказать в SETATTR этого флага. При отказе следует вернуть NFS4ERR_ACCESS или, в указанном случае прав владельца и привилегий, NFS4ERR_PERM; NFS4ERR_INVAL использовать нельзя. Последний код заставил бы клиентскую проверку поддержки принять отказ за незнание атрибута сервером. «Сервер умеет, но запрещает» и «сервер не умеет» требуют разных действий оператора; их нельзя сводить к одному статусу ошибки.

В официальной записи по-прежнему указана стадия I-D Exists. Описанные в тексте прототипы сервера Hammerspace и клиента Linux не доказывают распространённого внедрения, межплатформенной совместимости или конкретного инцидента с резервной копией. Новость касается границ предлагаемого механизма, а не гарантии уже работающей системы.

Источники