nfs mount falha devido ao mesmo identificador de arquivo

1

Em / etc / exports:

/tmp/test    *(rw)

/dev/sda1 (sistema de arquivos ext4) é montado em /tmp/test

comando para montar o nfs:

mount -o vers=3 $HOST:/tmp/test $NFS_DIR

(onde o HOST é o IP do servidor nfs, o NFS_DIR é o ponto de montagem local no cliente)

Na primeira vez, o nfs monta o sucesso. E então eu desmontei.

Em seguida, ordeno a entrada em / etc / exports (sem exportação do nfs) e faço exportfs -r .

Em seguida, descomenteço a entrada / tmp / test em / etc / exports (como antes) e faço exportfs -r novamente

E eu montei o compartilhamento nfs usando o mesmo comando. Mas desta vez, a montaria vai parar e expirar.

No entanto, quando eu checo o log do nfs, eu entendi:

/tmp and /tmp/test have same filehandle for *, using first
qword_eol: fflush failed: errno 22 (Invalid argument)
Cannot export /tmp, possibly unsupported filesystem or fsid= required" 

O erro de reclamação sobre exportação / tmp faz sentido porque é tmpfs.

Mas por que o / tmp e / tmp / test tem que lidar com o mesmo arquivo?

Eu sei que o problema é causado por / tmp e / tmp / test com o mesmo identificador de arquivo, então nfs retorna o primeiro que é / tmp. O que eu quero exportar é / tmp / test (ext4 fs), não / tmp (tmpfs).

O problema é resolvido reiniciando o rpc.mountd.

  1. por que / tmp / tmp / test obtém o mesmo identificador de arquivo?
  2. por que reiniciar o rpc.mountd resolve o problema?
  3. como resolver esse problema sem reiniciar o rpc.mounts?
por Shuo Dong 18.11.2015 / 08:19

1 resposta

1

Parece que é o bug do próprio nfs-utils. E esse bug é corrigido na versão 1.3.3. Eu também tentei usar o nfs-utls 1.3.2, mas o problema ainda está lá. Usar o nfs-utils 1.3.3 corrigirá este problema.

    
por 18.11.2015 / 21:34

Tags