Кратко

  • Рабочая группа NFSv4 выпустила 29 сентября редакцию -06 проекта об ACL. Предлагаемый необязательный атрибут ACL_Choice теперь занимает номер 89 вместо 87. Два других, тоже ещё не утверждённых проекта используют 87 для данных файла без кэширования и 88 для метаданных записей каталога.
  • Значения четырёх новых ошибок размера ACL перенесены с 20000–20003 на 10095–10098. Проект запрещает возвращать их без поддержки AclChoice сервером либо именно той файловой системой, к которой обращаются. В разделе ошибок по-прежнему отмечена необходимость согласия группы.

Если в дампе протокола появилось знакомое число, это ещё не ответ на вопрос, какой набор возможностей реально доступен клиенту. Новая версия ACLs within the NFSv4 Protocols хорошо показывает разницу. Редакция -05 от 14 сентября ставила ACL_Choice под номером 87. Редакция -06 от 29 сентября меняет и строку таблицы, и XDR-константу на 89. Авторское описание изменений прямо связывает перенос с двумя параллельными документами: uncacheable_file_data заявлен под номером 87, uncacheable_dirent_metadata — под 88.

Разведение номеров нужно для разных задач. ACL_Choice — предлагаемый необязательный способ сообщить клиенту о вариантах поведения ACL в переработанном описании NFSv4.1. Соседние атрибуты относятся к кэшированию файловых данных и метаданных каталога. Эта правка согласует черновики, но не является свидетельством сбоя в действующей сети. Из неё нельзя вывести, что какой-либо поставщик внедрил старое значение, а новые номера уже закреплены окончательным RFC.

Помимо атрибута, изменился диапазон четырёх ошибок для случаев, когда ACL не удаётся сохранить или вернуть из-за размера. Предыдущие значения 20000–20003 заменены на 10095–10098 для NFS4ERR_ACLST_POORFIT, NFS4ERR_ACLST_NOFIT, NFS4ERR_ACLST_TOOBIG и NFS4ERR_ACLFT_TOOBIG. Однако существеннее добавленное ограничение. Раз смысл ошибок зависит от сведений AclChoice, сервер без этого атрибута не должен их возвращать. Запрет действует и тогда, когда сервер в целом знаком с атрибутом, но целевая файловая система его не поддерживает.

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

Согласно Datatracker, -06 остаётся действующим Internet-Draft рабочей группы в состоянии I-D Exists. На титульной странице обновление RFC 7530 и RFC 8881 поставлено в зависимость от будущего одобрения. Текст только готовится к возможному последнему обсуждению в группе, а раздел ошибок сохраняет пометку о нерешённом консенсусе. Поэтому строгое слово MUST NOT в проекте нельзя выдавать за уже действующее требование опубликованного стандарта.

Источники