Montagens NFS sendo desmontadas, possivelmente pelo kernel

1

Recentemente, em algumas máquinas, os pontos de montagem começaram a desaparecer (um ponto de montagem por servidor, em intervalos aleatórios e máquinas aleatórias) e não consigo encontrar nada nos logs. Eu tenho cinco pontos de montagem e, aleatoriamente, qualquer um deles irá embora. Não há relação entre o desaparecimento e o protocolo mountpoint (as montagens TCP e UDP desaparecerão).

O que eu não tentei
Execute tcp dump continuamente (e estou relutante em fazer isso, já que esse problema acontece uma vez a cada 2-3 dias ...)

Informações sobre as máquinas :
NFS inicializado, o servidor de inicialização é o FreeBSD 11.0. (nada nos seus logs) opções de rootfs são:
(rw,noatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=ADDRESS,mountvers=3,mountport=677,mountproto=udp,local_lock=all,addr=ADDRESS)
OS é o CentOS7, rodando o kernel ML 4.11.0-1. Exemplo de opções de montagem:
rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=ADDRESS,mountvers=3,mountport=4002,mountproto=udp,local_lock=none,addr=ADDRESS) (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=udp,timeo=11,retrans=3,sec=sys,mountaddr=ADDRESS,mountvers=3,mountport=4002,mountproto=udp,local_lock=none,addr=ADDRESS,_netdev)
Informações sobre os compartilhamentos e servidor NFS
Eu tenho no total 5 servidores NFS distintos, o balanceamento de carga é feito através do DNS, todos exportam os mesmos pontos de montagem (alguns compartilhamentos UDP, alguns TCP). O servidor que executa o servidor NFS é o RHEL 6.7 (Santiago), a versão do kernel 2.6.32-573.el6, o snfs-common / server / client é o 4.7.3. Como você também não adivinhou nada nos logs do servidor relacionados a esse problema. Exemplo de opções de exportação:
(rw,async,root_squash,no_wdelay,no_subtree_check,fsid=ID)
Coisas que tentei até agora:
Minha primeira suposição é que eu tenho um processo que chama umount ou umount2, através de algum motivo bizarro em um compartilhamento NFS aleatório, depois de rastrear com sysdig para unlinkat, unlink, desmontar e remover systemcalls, só consigo ver systemd-logind fazendo unmount2 quando uma sessão do usuário é destruída, mas não nos pontos de montagem. O filtro sysdig que eu usei em um cinzel é postado abaixo:
function on_init() local filename = path for i in string.gmatch(path, "[^/]+") do filename = i end print("PID\tPROC_NAME\tPROC_EXEC\tPROC_SID\tPROC_PNAME\tPROC_PPID\tPROC_EXELINE\tPROC_PCMDLINE") chisel.set_event_formatter("%proc.pid\t%proc.name\t%proc.exec\t%proc.sid\t%proc.pname\t%proc.ppid\t%proc.exeline\t%proc.pcmdline ") chisel.set_filter( "(evt.type=unlinkat and evt.arg.name=" .. path .. ") or \ (evt.type=unlink and evt.arg.path=" .. path .. ") or \ (evt.type=umount) or \ (evt.type=remove and evt.arg.path=" .. path .. ")") return true end
A desmontagem aconteceu novamente aleatoriamente, mas o filtro não conseguiu ver isso. Pensando que o filtro está com defeito, criei um programa que desmonta um compartilhamento com umount e umount2 (tentei os sinalizadores preguiçoso e force umount) e o filtro os detectou corretamente, então isso me faz acreditar que o kernel é umount coisas.
Eu não tenho nada em meus logs nem mesmo a mensagem usual "nfs não respondendo" quando há um problema com o compartilhamento.
Se eu fizer o login em uma máquina e remontar, a remontagem será bem-sucedida sem nenhum problema.
Eu tenho vários clientes executando a mesma configuração e isso não acontece lá. A única coisa que esse grupo de máquinas tem em comum é o segmento de rede e o servidor de inicialização NFS. Mas não consigo ver por que absolutamente nada será relatado se a comunicação entre o servidor e o cliente morrer.

    
por Hristo Mohamed 24.07.2017 / 18:47

1 resposta

1

Se alguém se importa, este foi um bug do NFS no kernel. Deve ser corrigido por commit cc89684c9a265828ce061037f1f79f4a68ccd3f7 .

NFS: only invalidate dentrys that are clearly invalid

Since commit bafc9b754f75 ("vfs: More precise tests in d_invalidate") in v3.18, a return of '0' from ->d_revalidate() will cause the dentry to be invalidated even if it has filesystems mounted on or it or on a descendant. The mounted filesystem is unmounted.

...

    
por 27.10.2017 / 14:40

Tags