Por que os eventos inotify são diferentes em uma montagem NFS?

Há algum tempo, notei que os eventos relatados pelo inotify são diferentes quando o arquivo é salvo em uma montagem NFS versus um sistema de arquivos local.

O VFS subjacente não deve fornecer uma visão uniforme das operações de arquivo?

A seguir está o rastreio do VIM salvando um arquivo no Debian 7.1 (Linux 3.2)

Em uma montagem NFS:

wd=1 mask = 32 (IN_OPEN)
wd=1 mask = 16 (IN_CLOSE_NOWRITE)
wd=1 mask = 2048 (IN_MOVE_SELF)
wd=1 mask = 4 (IN_ATTRIB)
wd=1 mask = 1024 (IN_DELETE_SELF)
wd=1 mask = 32768 )

Em um sistema de arquivos local

wd=1 mask = 32 (IN_OPEN)
wd=1 mask = 16 (IN_CLOSE_NOWRITE)
wd=1 mask = 2 (IN_MODIFY)
wd=1 mask = 32 (IN_OPEN)
wd=1 mask = 8 (IN_CLOSE_WRITE)
wd=1 mask = 4 (IN_ATTRIB)

Salvar um arquivo com o EMACS também revela diferentes recursos

Em uma montagem NFS:

wd=1 mask = 32 (IN_OPEN)
wd=1 mask = 16 (IN_CLOSE_NOWRITE)
wd=1 mask = 2048 (IN_MOVE_SELF)

Em um sistema de arquivos local:

wd=1 mask = 32 (IN_OPEN)
wd=1 mask = 16 (IN_CLOSE_NOWRITE)
wd=1 mask = 2 (IN_MODIFY)
wd=1 mask = 32 (IN_OPEN)
wd=1 mask = 2 (IN_MODIFY)
wd=1 mask = 8 (IN_CLOSE_WRITE)

Esses testes foram executados com o inotify-touch.c

inotificar suporte NFS?

Olhando ao redor da rede, parece que o inotify pode suportar NFS, mas de uma maneira muito limitada.

O motivo é explicado nas perguntas e respostas sobre o StackOverflow intitulado: inotify with NFS .

trecho da resposta aceita

O inotify requer suporte do kernel para funcionar. Quando um aplicativo rastreia um diretório, ele solicita ao kernel que o informe quando essas alterações ocorrerem. Quando a alteração ocorre, além de gravar essas alterações no disco, o kernel também notifica o processo de observação.

Em uma máquina NFS remota, a alteração não é visível para o kernel; isso acontece totalmente remotamente. O NFS é anterior ao inotify e não há suporte no nível da rede para ele no NFS, ou qualquer coisa equivalente.

Pesquisando um pouco mais, se você consultar as perguntas frequentes sobre inotify

P: Posso assistir ao sysfs (procfs, nfs ...)?

Simplesmente falado: sim, mas com algumas limitações. Essas limitações variam entre as versões do kernel e tendem a ficar menores. Por favor, leia as informações sobre sistemas de arquivos específicos.

Então, é suportado?

Acho que, no final das contas, o que você está enfrentando é que o NFS não fornece uma comparação entre maçãs dos mesmos recursos que os sistemas de arquivos montados localmente.

Por exemplo, de um encadeamento nfs linux :

• O CIFS possui recursos de notificação incorporados (oplocks)
• O NFS fornece "concessões" para notificação

O ponto aqui é que um sistema de arquivos alternativo, como CIFS e NFS, oferece suporte muito básico, se houver, diretamente à inotificação.

Estado do NFS v4

trecho do artigo da IBM sobre o estado do NFS v4

O NFS versão 4 fornece um protocolo para o cliente estabelecer ou restabelecer o estado e associa a propriedade das operações com estado do servidor subsequentes aos estados previamente estabelecidos. Para resolver o problema do cliente ausente, o cliente NFS versão 4 deve atualizar rotineiramente o estado dentro do tempo de concessão especificado pelo servidor. Após o tempo limite da concessão, o servidor pode liberar recursos para o cliente e disponibilizá-los para outros aplicativos.

• Um cliente obtém o atributo de tempo limite de concessão especificado pelo servidor emitindo uma operação getattr. getattr não é uma operação com estado, portanto, não requer que o estado anterior seja estabelecido. Uma operação getattr pode preceder uma operação setclientid ou setclientid_confirm.
• Consulte o atributo do site de tempo de espera do servidor NFS para definir e ajustar os períodos de concessão. *