FSID действительно нужен для экспорта NFS?

ссылка:

• последствия использования NFSv4 fsid=0 и экспорта корневого NFS на всю локальную сеть (или нет)
  экспорта-корневого-nfs-на-всю-локальную-сеть-или
• https://earlruby.org/2022/01/setting-up-nfs-fsid-for-multiple-networks/
  • Когда я настраиваю NFS-серверы, мне нравится назначать каждому экспортируемому тому уникальный FSID…
  • Если вы используете другой FSID для одной из этих записей или если вы объявляете FSID для одной подсети, а не для другой, ваш NFS-сервер будет медленно и таинственно останавливаться, иногда в течение часов, а иногда в течение дней.
    • кажется, что явное использование fsid в /etc/exports может вызвать проблемы?

из ссылки earlruby выше:

Если вы не используете FSID, существует вероятность того, что при перезагрузке вашего NFS-сервера способ, которым сервер идентифицирует том, изменится между перезагрузками, и ваши NFS-клиенты будут зависать с ошибками «устаревшая файловая дескрипция». Я говорю «вероятность», потому что это зависит от того, как ваш сервер хранит тома, какая версия NFS у него работает, и если это отказоустойчивый / высокодоступный сервер, как была реализована эта возможность высокой доступности. Использование уникального FSID гарантирует, что том, который сервер представляет, всегда будет идентифицирован одинаково, и это упрощает для NFS-клиентов повторное соединение и возобновление операций после перезагрузки NFS-сервера.

• https://linux.die.net/man/5/exports

В читая страницу man и другие ресурсы, я не понимаю реальную необходимость делать явное fsid=<некоторое число> в /etc/exports. Можете ли вы объяснить мне, когда и почему вы бы сделали такую вещь, в RHEL 8.9 или позже с NFS vers=4.2, особенно когда я лично никогда не использовал fsid= и никогда не имел проблем.

Когда один явно указывает fsid=<некоторое число> в /etc/exports, как выбирается этот идентификатор? Как вы гарантируете, что он уникален?

Если я только экспортирую папки NFS, которые являются локальными монтированиями, такими как /dev/sdb1 и /dev/sdc1, и монтирую их через UUID в своем /etc/fstab, и они являются файловыми системами XFS, гарантирует ли это, что мне не нужно использовать fsid= в /etc/exports? Что если одна из этих локально смонтированных файловых систем является NTFS-3g?

Какие файловые системы являются проблемными согласно описанию страницы man nfs? Не все файловые системы хранятся на устройствах… что это означает*?

Предоставленное описание довольно ясно, я думаю.

fsid является необязательной функцией. Без него другие факторы помогают идентифицировать файловую систему. Однако (как указано), эти «другие факторы» нестабильны и могут изменяться. Использование fsid для идентификации файловой системы повышает надежность, стабильность при перезагрузках и совместимость версий.

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

fsid является относительно новым вариантом (новым в NFSv4, я думаю), поэтому он может вызывать ошибки. Возможно, он не нужен для простых конфигураций и текущих версий. Он не был необходим в течение многих лет и, вероятно, останется необязательным для большинства конфигураций.

Но если у вас возникла проблема с алиасами или устаревшими nfs монтированиями после перезагрузки или обновлений, вы могли обнаружить, что он необходим…

Страница man exports(5) говорит:

NFS должен иметь возможность идентифицировать каждую файловую систему, которую он экспортирует. Обычно он будет использовать UUID для файловой системы (если такая имеется) или номер устройства устройства, на котором хранится файловая система (если файловая система хранится на устройстве).

Так что, если ваш NFS-сервер — это современный сервер Linux, клиенты с 2010 года или новее, и экспортируемые вами файловые системы имеют стабильные, уникальные UUID, указание fsid= при экспорте является необязательным.

Если ваша экспортируемая файловая система не имеет UUID файловой системы, но она содержится на устройстве, номер устройства (основной и побочный) которого останется стабильным после перезагрузки, указание fsid= при экспорте снова является необязательным.

Если вы действительно указываете опции экспорта fsid= в числовом формате, вам, вероятно, следует делать это для всех ваших NFS-экспортов, чтобы избежать конфликтов между вручную установленными и автоматически сгенерированными FSID.

Если вы клонируете файловые системы и не переназначаете их UUID после клонирования, не использование fsid= при ваших NFS-экспортах может когда-нибудь обернуться неприятностью. (При использовании таких типов файловых систем, как XFS или btrfs, клонирование файловых систем и затем незадание новых UUID для клонов может обернуться неприятностью даже без NFS-экспортов, поэтому наличие неуникальных UUID файловых систем в любом случае не является хорошей идеей.)

Если вы экспортируете какую-то виртуальную файловую систему, которая не основана на устройстве (например, вы монтируете удаленный SMB-общий ресурс, а затем повторно экспортируете его через NFS), вы можете обнаружить, что указание опции fsid= для такой файловой системы является обязательным. Без этой опции команда exportfs может просто завершиться неудачно… или, если она успешна, вы можете обнаружить, что ядро назначило некоторый случайный FSID для этого общего ресурса, который может не остаться тем же при перезагрузке системы NFS-сервера.

Каждый раз, когда NFS-клиент видит, что NFS-сервер был перезагружен, он может автоматически восстановить свои NFS-монтирования только в том случае, если FSID экспортируемых NFS-ресурсов остаются теми же, что и до перезагрузки. Если FSID изменился, любая попытка доступа к смонтированной NFS-файловой системе приведет к ошибке Устаревшая файловая дескрипция, до тех пор, пока NFS-монтирование не будет размонтировано и переустановлено (со стороны клиента) или ресурс NFS не будет повторно экспортирован (со стороны сервера) с тем же старым FSID.

Это связано с тем, что при изменении FSID клиент должен предположить, что основная файловая система на NFS-сервере больше не такая же, как раньше, и поэтому любые локально кэшированные данные больше не применимы к этому ресурсу NFS. Если в кэше клиента есть ожидающие операции записи NFS, и старый FSID не может быть восстановлен на стороне сервера, может потребоваться использовать umount -f со стороны клиента, чтобы сообщить ядру, что потеря кэшированных данных приемлема.

По той же причине, если вы реализуете резервирование NFS-сервера, вы должны быть очень осторожны, чтобы резервный/вторичный сервер использовал те же FSID для тех же файловых систем, что и первичный сервер.

FSID в формате UUID был представлен, очевидно, в 2007 году, в версии ядра 2.6.21. Если ваши NFS-клиенты старше этого, они будут использовать маленькие целые числа FSID, выводимые из номеров устройств, поэтому, если вы используете горячие подключаемые блочные устройства, порядок которых может изменяться с одной загрузки на другую, вам лучше использовать опцию экспорта fsid=, чтобы явно назначить FSID. То же самое, вероятно, верно, если у вас есть старые не-Linux NFS-клиенты, чей код клиента NFS не получал никаких обновлений функций с 2007 года или около того.

Страница man говорит:

Установка как маленького числа, так и UUID поддерживается, чтобы одна и та же конфигурация могла работать как на старых, так и на новых ядрах.

Я думаю, это означает, что если у вас есть сочетание старых и новых NFS-клиентов, то новые могут использовать FSID в стиле UUID, предоставленные драйверами файловой системы NFS-сервера, а старые могут использовать FSID малых целых чисел, выведенные из номеров устройств NFS-сервера (если вы их явно не указали).

FSID определенно существовали в NFSv3, возможно раньше; но может быть, что ранние реализации просто выводили FSID в стиле малых целых чисел из номеров устройств (или чего-то еще) и рассматривали их как внутреннюю реализацию, о которой пользователю не нужно было беспокоиться… пока кластеризация, SAN и другие сложные конфигурации не сделали очевидным, что в некоторых ситуациях действительно требуется возможность вручную устанавливать FSID. И так опция экспорта fsid= была введена.

(Я должен был указывать FSID на кластере HP-UX 11.00, который поддерживал только NFSv2 и NFSv3 в то время. Без опций экспорта fsid= кластерные NFS-ресурсы часто, но не всегда, терпели неудачу при переключении. Как только были добавлены опции fsid=, переключение стало работать надежно.)

Для NFSv4 fsid=0 (который также может быть указан как fsid=root) имеет особое значение: любая файловая система, экспортируемая с этой опцией, станет корнем всех экспортируемых файловых систем NFSv4.

На современных версиях Linux это также необязательно: если вы вообще не указываете fsid=0/fsid=root, ядро автоматически предоставит пустую виртуальную корневую NFS-файловую систему и сделает все NFS-экспорты дочерними этой файловой системе. Это делает NFSv4 экспорты похожими на NFSv3 и более ранние.

Но если вы не хотите раскрывать вашу фактическую структуру директорий NFS-сервера клиентам более чем это необходимо, вы можете хотеть использовать опцию fsid=0 и выбрать, как построить виртуальное дерево каталогов NFSv4 так, как вам нужно.

На более старых реализациях NFSv4 для Linux указание fsid=0 может быть обязательным. Я точно не помню, когда это стало необязательным.