Pourquoi les événements inotify sont-ils différents sur un montage NFS?

Il y a quelque temps, j'ai remarqué que les événements signalés par inotify sont différents lorsque le fichier est enregistré sur un montage NFS par rapport à un système de fichiers local.

Le VFS sous-jacent ne devrait-il pas fournir une vue uniforme des opérations sur les fichiers?

Ce qui suit est la trace de VIM enregistrant un fichier dans Debian 7.1 (Linux 3.2)

Sur un montage 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 )

Sur un système de fichiers 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)

L'enregistrement d'un fichier avec EMACS révèle également différents beahvior

Sur un montage NFS:

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

Sur un système de fichiers 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)

Ces tests ont été exécutés avec inotify-touch.c

inotifier le support NFS?

En regardant autour du net, il semblerait qu'inotify puisse prendre en charge NFS mais de manière très limitée.

La raison est expliquée dans ce Q&A StackOverflow intitulé: inotify avec NFS .

extrait de la réponse acceptée

inotify nécessite le support du noyau pour fonctionner. Lorsqu'une application suit un répertoire, elle demande au noyau de l'informer lorsque ces changements se produisent. Lorsque le changement se produit, en plus d'écrire ces modifications sur le disque, le noyau notifie également le processus d'observation.

Sur une machine NFS distante, la modification n'est pas visible pour le noyau; cela se produit entièrement à distance. NFS est antérieur à inotify et il n'y a pas de prise en charge au niveau du réseau dans NFS, ou quoi que ce soit équivalent.

En recherchant un peu plus si vous regardez dans la FAQ inotify

Q: Puis-je regarder des sysfs (procfs, nfs ...)?

Pour parler simplement: oui, mais avec quelques limitations. Ces limitations varient entre les versions du noyau et tendent à devenir plus petites. Veuillez lire les informations sur des systèmes de fichiers particuliers.

Est-il donc pris en charge?

Je pense qu'en fin de compte, ce que vous rencontrez est que NFS ne fournit pas de pommes aux pommes équivalentes à toutes les mêmes fonctionnalités que les systèmes de fichiers montés localement.

Par exemple à partir d'un thread linux nfs :

• CIFS a des capacités de notification intégrées (oplocks)
• NFS fournit des «baux» pour la notification

Le point ici est que les systèmes de fichiers alternatifs tels que CIFS et NFS offrent un support très basique, voire aucun, directement pour inotify.

État NFS v4

extrait d'un article IBM sur l'état de NFS v4

La version 4 de NFS fournit un protocole permettant au client d'établir ou de rétablir l'état et associe la propriété des opérations ultérieures avec état du serveur aux états précédemment établis. Pour résoudre le problème du client absent, le client NFS version 4 doit régulièrement actualiser l'état dans le délai de location spécifié par le serveur. À l'expiration du bail, le serveur peut libérer des ressources pour le client et les mettre à la disposition d'autres applications.

• Un client obtient l'attribut de délai d'expiration de bail spécifié par le serveur en émettant une opération getattr. getattr n'est pas une opération avec état, il ne nécessite donc pas l'établissement d'un état préalable. Une opération getattr peut précéder une opération setclientid ou setclientid_confirm.
• Reportez-vous à l'attribut de site de durée de vie du serveur NFS pour définir et régler les périodes de location. *