Modificações de arquivos atrasadas

Question

Estamos tendo um problema estranho em que a criação / remoção de arquivos de um cliente NFS leva muito tempo para se propagar para o (s) outro (s) cliente (s).

As opções de montagem que temos nos clientes são:

defaults,rsize=32768,wsize=32768,intr,noatime,cto

A exportação tem:

*(rw,sync,no_root_squash,no_wdelay)

Verificamos isso em um cliente:

watch -n0.1 stat foofile

E em outro cliente, tocamos foofile (ou rm it). As modificações demoram mais de 1 segundo para se propagar.

cto e no_wdelay são opções que acabamos de adicionar para ver se elas resolvem o problema (elas não). O que mais podemos ver?

    

Answer 1

Não vou responder à sua pergunta diretamente.

Os clientes do NFS não têm garantia de ver as atualizações muito rapidamente. Sim, você pode ajustar os parâmetros para controlar o atraso, mas o resultado será um pior armazenamento em cache (e, portanto, um desempenho terrível) nos clientes.

Normalmente, quando me vejo precisando de clientes NFS para ver as mudanças mais rapidamente, eu dou um passo para trás e pergunto, "ok, o que estou realmente tentando conseguir aqui?" Normalmente, percebo que existe algum nível mais alto de abstração que me permite resolver o mesmo problema de uma maneira muito diferente. Por exemplo, às vezes percebo que estou tentando usar arquivos NFS como RPC ou mecanismo de bloqueio de um homem pobre. Existem maneiras muito melhores de fazer qualquer uma dessas coisas.

O NFS é bom para um único cliente que acessa um diretório específico. Fora disso, se você tiver um problema e for consertá-lo com o NFS, você terá dois problemas.

Eu adoro o NFS, mas ele é limitado em onde eu tento usá-lo.

    

Answer 2

Não é de modo algum certo que seja um problema seu, mas às vezes encontrei problemas de coerência com o NFS, onde os clientes e o servidor nem todos têm clocks rigidamente sincronizados. Todos os sistemas envolvidos estão sincronizados com o NTP?