☰

Сервер NFS v4 вызывает устаревание дескриптора файла, но только когда привязка монтирования является подкаталогом

tag-icon • tag-icon linux ubuntu nfs nfs4
Сервер NFS v4 вызывает устаревание дескриптора файла, но только когда привязка монтирования является подкаталогом

Эта проблема в данный момент сводит меня с ума. У меня есть сервер Ubuntu 16.04 NFS, который отлично работал с этой конфигурацией:

/etc/fstab:
UUID=b6bd34a3-f5af-4463-a515-be0b0b583f98  /data2  xfs  rw,relatime  0  0
/data2  /srv/nfs/cryodata    none    defaults,bind    0  0
/usr/local       /srv/nfs/local    none    defaults,bind    0  0

и

/etc/exports
/srv/nfs  192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata  192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local      192.168.159.31(rw,sync,no_subtree_check)

Все это прекрасно работало в течение нескольких месяцев на одном клиенте nfs, использующем эту конфигурацию, при этом использовались следующие записи /etc/fstab на стороне клиента:

kraken.bio.univ.edu:/local  /usr/local  nfs4  _netdev,auto  0  0
kraken.bio.univ.edu:/cryodata  /cryodata  nfs4  _netdev,auto  0  0

Однако, поскольку это очень большой сервер хранения, было решено, что он должен вмещать несколько лабораторий. Поэтому я переместил все, что было разбросано по разделу /data2, в подкаталог /data2/cryodata и обновил /etc/fstab на сервере и /etc/exports следующим образом:

/etc/fstab:
...
/data2/cryodata  /srv/nfs/cryodata    none    defaults,bind    0  0
/data2/xray      /srv/nfs/xray    none    defaults,bind    0  0
/data2/EM        /srv/nfs/EM    none    defaults,bind    0  0
/usr/local       /srv/nfs/local    none    defaults,bind    0  0

и

/etc/exports
/srv/nfs  192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata  192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/EM  192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/xray  192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local  192.168.159.31(rw,sync,no_subtree_check)

Это просто не работает! Когда я пытаюсь смонтировать новое монтирование на клиенте, используя ту же запись в клиентском /etc/fstab:

{nfs client} /etc/fstab:
...
kraken.bio.univ.edu:/local  /usr/local  nfs4  _netdev,auto  0  0
kraken.bio.univ.edu:/cryodata  /cryodata  nfs4  _netdev,auto  0  0

.

# mount -v /cryodata
mount.nfs4: timeout set for Sat Feb 24 09:24:38 2018
mount.nfs4: trying text-based options 'addr=192.168.41.171,clientaddr=192.168.159.31'
mount.nfs4: mount(2): Stale file handle
mount.nfs4: trying text-based options 'addr=192.168.41.171,clientaddr=192.168.159.31'
mount.nfs4: mount(2): Stale file handle
mount.nfs4: trying text-based options 'addr=128.83.41.171,clientaddr=129.116.159.31'
...

/usr/local продолжает монтироваться без проблем. В первый раз, когда я попробовал это, я забыл отменить экспорт/экспортировать файловые системы, используемые exportfs -varперед внесением изменений, но с тех пор я переключался туда-сюда, внимательно отменяя экспорт и размонтируя все, с несколькими перезагрузками сервера между ними. Первоначальное монтирование привязки монтирования всего раздела всегда работает, а привязка монтирования подкаталога каждый раз завершается сбоем с сообщением stale nfs handle. Я пробовал включить другие клиенты nfs, которые никогда не монтировали эти разделы, и получаю точно такое же сообщение об ошибке: в этом случае это определенно проблема на стороне сервера. Я проверил /var/lib/nfs/etab, чтобы убедиться, что он очищается между попытками монтирования и т. д.

Я думал, что техника привязки монтирования в корневой каталог сервера nfs решает все эти проблемы, но, видимо, нет? Странно, что /usr/local является подкаталогом другого раздела, и он всегда нормально монтируется. Он находится на ext3 md raid 1, хотя я не могу себе представить, что это имеет значение.

Я потратил на это часы и почти сломал Google в поисках решения, но безрезультатно.

решение1

Обратите внимание, что я экспортирую только смонтированные файловые системы. Этот раздел изэкспортСтраница руководства актуальна:

fsid=номер|корень|uuid

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

Мое ошибочное предположение заключалось в том, что файловые системы, смонтированные с помощью bind, имеют некий UUID, который NFS может использовать автоматически; и это предположение подкреплялось тем фактом, что оба этих экспорта, смонтированных с помощью bind, прекрасно работали без fid:

/srv/nfs  192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata  192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local  192.168.159.31(rw,sync,no_subtree_check)

Однако это приводит к непоследовательному поведению. Я добавил привязку, смонтированную /opt:

/etc/fstab:
/data1/opt      /srv/nfs/opt  none  defaults,bind    0  0

/etc/exports:
/srv/nfs/opt  192.168.159.3(rw,sync,no_subtree_check)

приводило к непоследовательному поведению; т.е. можно было изменить экспортный IP и смонтировать на одной машине, но получить отказ в разрешении на другой. Решением было добавить fid:

/etc/exports:
/srv/nfs/opt  192.168.159.3(rw,sync,fsid=20,no_subtree_check)

Поэтому решение — всегда добавлять fid для экспорта смонтированных файловых систем.

Связанный контент