voltar a tocar ficheiros por sshfs

Question

O sistema de arquivos da máquina A está montado na máquina B via sshfs . Um processo em execução no B , que foi iniciado a partir de A por ssh touch es um arquivo no sistema de arquivos montado de A para comunicar um sinal; o sinal (arquivo) é então removido por A . Isso funciona de forma confiável na primeira vez em que o arquivo é criado / destruído ( touch / rm ).

No entanto, se um segundo processo (novamente, executado em B , gerada a partir de A ) tentar tocar exatamente o mesmo arquivo, o seguinte erro é esporadicamente lançado:

'touch: cannot touch '/path/to/file': No such file or directory'.

O caminho é válido conforme julgado pelo fato de que tentativas para touch manualmente após o erro ser lançado são uniformemente bem-sucedidas. Como mencionado, o erro é esporádico (complicando as tentativas de depuração), mas só ocorre quando o arquivo é tocado após já ter passado por um ciclo de criação / exclusão.

As ações que geram intermitentemente um erro ( touch , rm , touch ) são separadas no tempo, portanto é improvável que o acesso simultâneo seja o culpado (ou seja, o segundo toque não acontece até que o arquivo produzido por o primeiro toque é removido). Pensando que a causa pode derivar do buffer do sistema de arquivos, sync é chamado de A após a remoção do arquivo, sem sucesso. Chamar sync de B imediatamente antes de tocar no arquivo também não ajuda, embora eu não saiba se B ' sync call afeta o sistema de arquivos de A (a versão de sync on B não possui a opção -f para especificação explícita do sistema de arquivos, tentei chamar sync on A do processo em execução no B via ssh user@A sync before touch ing mas o processo parece sair sem erro logo após a chamada sync-over-ssh, já que as linhas restantes, incluindo a instrução touch , não são executadas, talvez porque não é possível ssh do servidor voltar para o cliente em um processo iniciado por ssh do cliente para o servidor).

Como a causa desse erro relacionado ao sistema de arquivos pode ser determinada?

    

Answer 1

Você pode investigar o que pode estar acontecendo executando o sshfs com a opção -o debug . Ele imprime muitas informações sobre as operações básicas do sistema de arquivos feitas por um comando touch test . Uma operação de exemplo é:

unique: 209, opcode: LOOKUP (1), nodeid: 1, insize: 45, pid: 10641
LOOKUP /test
getattr /test
   NODEID: 44
   unique: 209, success, outsize: 144

A parte relevante é que uma chamada getattr foi feita e terminou em sucesso. Quando você toca com sucesso em um arquivo inexistente, as operações que vemos são (removendo os detalhes):

getattr /test
   unique: 190, error: -2 (No such file or directory), outsize: 16
create flags: 0x8841 /test 0100644 umask=0022
fgetattr[140469187119648] /test
flush[140469187119648]
utime /test 1507647885 1507647885
getattr /test
flush[140469187119648]
release[140469187119648] flags: 0x8801

Nós vemos o teste getattr para o arquivo falhar, o que é normal, pois não existe, então vamos criar o arquivo.

Se o arquivo for removido agora no servidor e fizermos o toque novamente no cliente, veremos uma sequência diferente:

getattr /test
   unique: 215, success, outsize: 144
open flags: 0x8801 /test
   unique: 216, error: -2 (No such file or directory), outsize: 16

Agora, o getattr diz que o arquivo ainda existe, então touch passa para open() do arquivo, mas isso resulta em sua mensagem de erro: o arquivo realmente não existe.

Portanto, tudo parece ser um problema do cache do cliente de quais arquivos estão sendo lentos demais para acompanhar as mudanças no controle remoto. A resposta mais simples é montar seu controle remoto com um tempo limite menor para a chamada getattr , ou seja, a chamada do sistema stat() . Isso deve funcionar para você

sshfs -o cache_stat_timeout=0 ...