¿Por qué los eventos de inotify son diferentes en un montaje NFS?

Hace algún tiempo, noté que los eventos informados por inotify son diferentes cuando el archivo se guarda en un montaje NFS frente a un sistema de archivos local.

¿No debería el VFS subyacente proporcionar una vista uniforme de las operaciones de archivos?

La siguiente es la traza de VIM guardando un archivo en Debian 7.1 (Linux 3.2)

En un montaje 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 )

En un sistema de archivos 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)

Guardar un archivo con EMACS también revela diferentes comportamientos

En un montaje NFS:

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

En un sistema de archivos 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)

Estas pruebas se ejecutaron con inotify-touch.c

inotify soporte NFS?

Mirando alrededor de la red, parecería que inotify puede soportar NFS pero de manera muy limitada.

La razón se explica en estas preguntas y respuestas de StackOverflow tituladas: inotify con NFS .

extracto de la respuesta aceptada

inotify requiere soporte del kernel para funcionar. Cuando una aplicación rastrea un directorio, le pide al núcleo que le informe cuándo ocurren esos cambios. Cuando se produce el cambio, además de escribir esos cambios en el disco, el núcleo también notifica el proceso de observación.

En una máquina remota NFS, el cambio no es visible para el núcleo; Sucede de forma totalmente remota. NFS es anterior a inotify y no hay soporte de nivel de red para ello en NFS, ni nada equivalente.

Investiga un poco más si miras en las preguntas frecuentes de inotify

P: ¿Puedo ver sysfs (procfs, nfs ...)?

En pocas palabras: sí, pero con algunas limitaciones. Estas limitaciones varían entre las versiones del kernel y tienden a ser más pequeñas. Lea la información sobre sistemas de archivos particulares.

Entonces, ¿es compatible?

Creo que, en última instancia, lo que está experimentando es que NFS no proporciona un equivalente de manzanas a manzanas de las mismas características que los sistemas de archivos montados localmente.

Por ejemplo de un hilo linux nfs :

• CIFS tiene capacidades de notificación integradas (oplocks)
• NFS proporciona "arrendamientos" para notificación

El punto aquí es que el sistema de archivos alternativo, como CIFS y NFS, ofrece soporte muy básico, si es que hay alguno, directamente para la notificación.

Estado NFS v4

Extracto del artículo de IBM sobre el estado NFS v4

La versión 4 de NFS proporciona un protocolo para que el cliente establezca o restablezca el estado, y asocia la propiedad de las operaciones con estado posteriores del servidor a los estados previamente establecidos. Para resolver el problema del cliente ausente, el cliente NFS versión 4 debe actualizar periódicamente el estado dentro del tiempo de arrendamiento especificado por el servidor. Tras el tiempo de espera de arrendamiento, el servidor puede liberar recursos para el cliente y ponerlos a disposición de otras aplicaciones.

• Un cliente obtiene el atributo de tiempo de espera de arrendamiento especificado por el servidor emitiendo una operación getattr. getattr no es una operación con estado, por lo tanto, no requiere que se establezca un estado previo. Una operación getattr puede preceder a una operación setclientid o setclientid_confirm.
• Consulte el atributo del sitio de tiempo de vida del servidor NFS para configurar y ajustar los períodos de tiempo de arrendamiento. * *