Início / server / Perguntas / 898725
Accepted
pgoetz
Asked: 2018-02-25 08:49:55 +0800 CST

O servidor NFS v4 está causando um identificador de arquivo obsoleto, mas somente quando a montagem de ligação é um subdiretório

  • 772

Este problema está basicamente me deixando louco, neste momento. Eu tenho um servidor Ubuntu 16.04 NFS que estava funcionando bem com esta configuração:

/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

e

/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)

Tudo isso tem funcionado bem por meses no cliente nfs usando esta configuração até agora usando estas entradas /etc/fstab do lado do cliente:

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

No entanto, como este é um servidor de armazenamento muito grande, foi decidido que ele precisa acomodar vários laboratórios. Então, movi todas as coisas que estavam espalhadas pela partição /data2 para um subdiretório /data2/cryodata e atualizei /etc/fstab no servidor e /etc/exports da seguinte forma:

/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

e

/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)

Isso simplesmente não funciona! Quando tento montar a nova montagem no cliente usando a mesma entrada /etc/fstab do cliente:

{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'
...

O /usr/local continua a ser montado sem problemas. A primeira vez que tentei isso, esqueci de desexportar/exportar os sistemas de arquivos usando exportfs -varantes de fazer alterações, mas desde então mudei para frente e para trás, tomando cuidado para desexportar e desmontar tudo, com várias reinicializações de servidor no meio. A montagem original de uma montagem de ligação de toda a partição sempre funciona, e a montagem de ligação de um subdiretório falha com a mensagem de manipulação nfs obsoleta todas as vezes. Eu tentei habilitar outros clientes nfs que nunca montaram essas partições e obtive exatamente a mesma mensagem de erro: neste caso, é definitivamente um problema do lado do servidor. Eu verifiquei /var/lib/nfs/etab para ter certeza de que está limpo entre tentativas de montagem, etc.

Eu pensei que a técnica de montagem de ligação em um diretório raiz do servidor nfs resolveu todos esses tipos de problemas, mas aparentemente não? O estranho é que /usr/local é um subdiretório de outra partição e sempre monta bem. Está em um ext3 md raid 1, embora eu não consiga imaginar que isso importe.

Passei horas nisso e quase quebrei o google procurando uma solução sem sucesso.

linux

1 respostas

  1. Best Answer

    Observe que estou exportando apenas sistemas de arquivos montados em bind. Esta seção da página de manual de exportação é relevante:

    fsid=num|root|uuid

    O NFS precisa ser capaz de identificar cada sistema de arquivos que exporta. Normalmente, ele usará um UUID para o sistema de arquivos (se o sistema de arquivos tiver tal coisa) ou o número do dispositivo que contém o sistema de arquivos (se o sistema de arquivos estiver armazenado no dispositivo).

    Minha suposição errônea era que os sistemas de arquivos montados em bind têm algum tipo de UUID que o NFS pode usar automaticamente; e suposição reforçada pelo fato de que ambas as exportações montadas em bind funcionaram bem sem um 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)

    No entanto, isso resulta em comportamento inconsistente. Eu adicionei um bind montado /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)

    resultou em comportamento inconsistente; ou seja, poderia alterar o IP de exportação e montar em uma máquina, mas obter permissão negada em outra. A solução foi adicionar um fsid:

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

    Portanto, a solução é sempre adicionar um fsid para exportar sistemas de arquivos montados em bind.

    • 3

relate perguntas