inotify avec NFS
J'ai récemment créé un système de dépôt utilisant inotify, surveillant les fichiers créés dans un répertoire particulier. Le répertoire que je regarde est monté à partir d'un serveur NFS et inotify se comporte différemment que prévu. Considérez le scénario suivant dans lequel un script inotify est exécuté sur la machine A en regardant/some/nfs/dir/also/visible/to/B.
-Utilisant la machine A pour créer un fichier dans/some/nfs/dir/also/visible/to/B, le script se comporte comme prévu. En utilisant la machine B pour effectuer la même action, le script n'est pas averti d'un nouveau fichier déposé dans le répertoire.
- Lorsque le script est exécuté sur le serveur NFS, il est averti lorsque des fichiers sont créés à partir de la machine A et de la machine B.
S'agit-il d'un bogue dans le paquet que j'utilise pour accéder à inotofy, ou s'agit-il d'un comportement attendu?
Cordialement,
Andrew
inotify nécessite le support du noyau pour fonctionner. Lorsqu'une application suit un répertoire, elle demande au noyau de l'informer de ces modifications. Lorsque la modification se produit, en plus d'écrire ces modifications sur le disque, le noyau informe également le processus de surveillance.
Sur une machine NFS distante, la modification n'est pas visible par le noyau. cela se passe entièrement à distance. NFS est antérieur à inotify et il n’ya aucune prise en charge au niveau du réseau dans NFS, ou quelque chose d’équivalent.
Si vous souhaitez contourner ce problème, vous pouvez exécuter un service sur le serveur de stockage (car ce noyau verra toujours les modifications apportées au système de fichiers) qui courtise les demandes de modification des ordinateurs distants et transfère les données aux clients distants.
Edit: Il me semble étrange que NFS soit blâmé pour son manque de support pour inotify.
NFS (Network File System) est un protocole de système de fichiers distribué développé à l'origine par Sun Microsystems en 1984, article de wikipedia
Toutefois:
Inotify (inode notify) est un sous-système du noyau Linux qui étend les systèmes de fichiers pour signaler les modifications apportées au système de fichiers. [...] Il a été inclus dans le noyau Linux principal à partir de la version 2.6.13 (18 juin 2005) [...]. article de wikipedia
Il est difficile de s'attendre à ce qu'un protocole/une application de réseau portable prenne en charge une fonctionnalité de noyau spécifique développée pour un système d'exploitation différent et apparue plus de vingt ans plus tard. Même si avait _ incluait des extensions, celles-ci ne seraient ni disponibles ni utiles sur d'autres systèmes d'exploitation.
* accent mien dans tous les cas
Un autre problème avec cela; Supposons que nous n'utilisons pas du tout de réseau, mais plutôt un système de fichiers local avec un bon support inotify: ext3 (supposons qu'il soit monté à /mnt/foo). Mais au lieu d’un vrai disque, le système de fichiers est monté à partir d’un périphérique en boucle; et le fichier sous-jacent est à son tour accessible à un emplacement différent dans le fichier vfs (par exemple, /var/images/foo.img).
Maintenant, vous n'êtes pas censé modifier les systèmes de fichiers ext3 montés, mais il est raisonnablement prudent de le faire si la modification consiste à archiver le contenu au lieu de métadonnées.
Supposons donc qu'un utilisateur intelligent modifie l'image du système de fichiers (/var/images/foo.img) dans un éditeur hexadécimal, en remplaçant le contenu d'un fichier par d'autres données, tout en observant le même fichier sur le système de fichiers monté.
Il n’existe aucun moyen raisonnable pour inotify de toujours informer le processus de surveillance de ce type de changement. Bien qu'il soit probable que certaines girations soient nécessaires pour rendre ext3 avis et honorer le changement, rien de tout cela ne s'appliquerait, par exemple, à xfs drtiver, qui est par ailleurs assez similaire.
Ni devrait le. Vous trichez!. inotify peut uniquement vous informer des modifications apportées via la vfs au point de montage actuellement surveillé. Si les modifications ont eu lieu en dehors de ce système VFS, inotify ne peut pas vous aider et n'est pas conçu pour résoudre ce problème, en raison d'une modification des données sous-jacentes.
Avez-vous envisagé d'utiliser une file de messages pour la notification réseau?
Pour tous ceux qui ont rencontré cette question dans la recherche d'une réponse à la question de savoir pourquoi le montage lié sur Docker ne détectera pas les modifications de fichier depuis le répertoire de l'hôte (pour le rechargement à chaud d'une application), c'est parce que la propagation des modifications de fichier entre l'hôte et le conteneur ne communiquée au noyau du conteneur.
Seules les modifications du conteneur lui-même sont communiquées au noyau. La solution pour cela est d’avoir votre utilitaire Live Reload activer le "mode de sondage" au lieu d’utiliser fsnotify.
Je seconde @SingleNegationElimination.
En outre, vous pouvez essayer notify-forwarder .
- La machine A surveille les événements inotify locaux, puis les transmet à la machine B (via UDP).
- La machine B ne lit pas (ne peut pas?) Les événements, mais déclenche un événement ATTRIB pour le fichier modifié.
Si vous utilisez vagant, utilisez vagrant-notify-forwarder .
Je suis d'accord avec l'explication de SingleNegationElimination et voudrais ajouter que les cibles iSCSI fonctionneront, car elles alertent le noyau.
Donc, les choses sur des systèmes de fichiers "réels" (par rapport au système) déclenchent une alerte Inotify. Comme Rsync'ing, net-catting quelque chose dans une partition montée.
Si vous devez recevoir des notifications via inotify (ou si vous devez utiliser inotify), vous pouvez envoyer un cron à rsync -avz sur le système de fichiers. Bien entendu, les inconvénients sont que vous utilisez un véritable espace disque dur système.