File Handle NFS obsoleto por que o fsid resolve isso?

Question

Declaração do problema (observe que esse problema foi resolvido, mas há uma pergunta sobre por que a solução funciona)

O servidor NFS é o Ubuntu 16.04.4 LTS. Os clientes são uma mistura de Ubuntu 16.04.4 LTS e CentOS 6.10 e 7.

O servidor NFS tem funcionado bem durante meses e uma exportação específica estava atendendo a vários clientes para seus backups. O diretório do servidor NFS ficou assim:

/mnt/backups/client1
/mnt/backups/client2
/mnt/backups/client3
/mnt/backups/client4

O / etc / exports continha:

/mnt/backups 1.2.3.0/24(rw,sync,no_subtree_check)

O cliente monta apenas o servidor nfs durante um backup e, em seguida, desmonta o backup quando ele é feito.

Isso estava funcionando bem, no entanto, foi determinado que os clientes não deveriam poder ver uns aos outros no diretório / mnt / backups. Cada cliente está usando o mesmo backup uid / gid. Portanto, foi decidido separar os diretórios através do uso do arquivo / etc / exports.

Para isso, o servidor NFS foi parado e o / etc / exports foi modificado para conter:

/mnt/backups/client1 1.2.3.21(rw,sync,no_subtree_check)
/mnt/backups/client2 1.2.3.22(rw,sync,no_subtree_check)
/mnt/backups/client3 1.2.3.23(rw,sync,no_subtree_check)
/mnt/backups/client4 1.2.3.24(rw,sync,no_subtree_check)

Lembre-se, o cliente monta somente o servidor NFS quando está fazendo um backup (às 4h). No servidor, o serviço NFS foi reiniciado e as exportações são verificadas com exportfs, parece bom.

OK, testando o client1:

mount nfserver:/mnt/backups/client1 /mnt/client1

funciona bem, no entanto, qualquer ação em / mnt / client1 resulta em:

cannot open directory /mnt/client1/: Stale file handle

Ações tomadas para resolver (que não funcionou) : Reiniciando o NFS no servidor. Reiniciando o cliente. lsof | grep / mnt no cliente e servidor para ver se algum programa estava mantendo os arquivos abertos. Permissões verifica no servidor / cliente. Novamente, mudar o NFS / etc / exports de volta para o arquivo antigo e montar o servidor nfs do cliente funciona. Mudar de volta para o "novo" método não funciona.

Depois de muito ranger de dentes, man pages e STFW apenas para encontrar respostas como "restart NFS", lembrei que tinha esse problema anos atrás e, por algum motivo, o fsid tinha algo a ver com a solução. Depois de ler as man pages, o seguinte foi incluído no arquivo / etc / exports do servidor NFS:

/mnt/backups/client1 1.2.3.21(fsid=101,rw,sync,no_subtree_check)
/mnt/backups/client2 1.2.3.22(fsid=102,rw,sync,no_subtree_check)
/mnt/backups/client3 1.2.3.23(fsid=103,rw,sync,no_subtree_check)
/mnt/backups/client4 1.2.3.24(fsid=104,rw,sync,no_subtree_check)

Mais uma vez, após essa ação, a única coisa executada foi um exportfs -ra no servidor.

Agora, todos os clientes podem montar as exportações do servidor nfs e todos eles funcionam.

Por que isso é uma solução?

Devemos usar o fsid em todas as exportações?

Ler uma página de manual como esta não parece explicar claramente por que o fsid é uma solução. Eu tinha uma idéia de que poderia ser que a montagem obsoleta fosse algum tipo de manipulador de arquivos NFS no lado do cliente (ou talvez no lado do servidor), mas para isso persistir após uma reinicialização pareceria estranho.

    

Answer 1

Em suma, o fsid é a maneira como o cliente e o servidor identificam uma exportação depois de montada.

Como afirma a página man, o fsid será derivado do sistema de arquivos subjacente, se não for especificado.

As quatro exportações têm o mesmo fsid, então é possível que quando o client1 estiver perguntando sobre os arquivos de sua montagem, o servidor pense que está tentando acessar a exportação do client4 (supondo que esteja mantendo a ocorrência mais recente do mesmo fsid). / p>

Eu acho que existem algumas maneiras de validar essa hipótese, por exemplo, verificando se um (e apenas um) dos 4 clientes funcionará. Também mantendo apenas a exportação client1, sem os outros 3, e confirmando o client1 irá funcionar.

Veja também esta resposta para uma maneira de consultar o fsid de um cliente, usando o comando mountpoint -d , que você poderia usar dos 4 clientes para confirmar que as 4 montagens têm o mesmo fsid.

Por que isso é uma solução?

Como com o fsid distinto, as exportações parecerão distintas do servidor NFS, portanto, ele corresponderá adequadamente aos acessos do cliente às suas montagens correspondentes.

Devemos usar fsid em todas as exportações?

Sim, acho que é uma boa prática, pois garante que você manterá o controle e as alterações nos dispositivos de armazenamento subjacentes e as exportações não afetarão seus clientes.

(No meu caso, lembro-me de tê-lo adotado, pois alguns dos meus servidores NFS com discos em uma SAN às vezes examinavam discos em uma ordem diferente, portanto, após uma reinicialização / dev / sdh, de repente se tornava / dev / sdj. Os rótulos asseguravam que ele seria montado no local correto, mas o fsid mudaria e os clientes se perderiam. Isso é antes da onipresença dos UUIDs, que aparentemente agora são suportados e são, obviamente, uma solução muito melhor para isso, que não quebrar quando os discos são digitalizados em uma ordem diferente.Mas, ainda, especificando o fsid explicitamente não é uma má idéia, permite que você mantenha o controle total.