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

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

/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 , прежде чем вносить изменения, но с тех пор я переключался туда и обратно, стараясь не экспортировать и размонтировать все, с несколькими сервер перезагружается между ними. Первоначальное монтирование привязки всего раздела всегда работает, а монтирование подкаталога с привязкой каждый раз завершается ошибкой с сообщением устаревшего дескриптора nfs. Я попытался включить другие клиенты nfs, которые никогда не монтировали эти разделы, и получил точно такое же сообщение об ошибке: в этом случае это определенно проблема на стороне сервера. Я проверил / var / lib / nfs / etab, чтобы убедиться, что он очищен между попытками монтирования и т. Д.

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

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

1
задан 24 February 2018 в 18:49
1 ответ

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

fsid = num | root | uuid

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

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

/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-адрес и смонтировать на одном компьютере, но получить разрешение на другом отказано. Решением было добавить fsid:

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

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

3
ответ дан 3 December 2019 в 18:28

Теги

Похожие вопросы