inotify avec NFS
J'ai récemment créé un système dropbox en utilisant inotify, en recherchant 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 de ce à quoi je m'attendais. Considérons 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.
- en utilisant la machine a pour créer un fichier dans/some / NFS / dir / also / visible / to / B, le script se comporte comme prévu. Utilisation de la machine B pour effectuer le 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.
Est-ce un bogue dans le bogue du paquet que j'utilise pour accéder à inotofy, ou est-ce un comportement attendu?
Cordialement,
Andrew
4 réponses
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 modifications se produisent. Lorsque le changement se produit, en plus d'écrire ces modifications sur le disque, le noyau avertit également le processus de surveillance.
Sur une machine NFS distante, la modification n'est pas visible pour le noyau; elle 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 d'équivalent.
Si pour contourner ce problème, vous pouvez exécuter un service sur le serveur de stockage (puisque ce noyau verra toujours les modifications du système de fichiers) qui traite les demandes inotify pour les machines distantes et transmet les données aux clients distants.
Edit: Il me semble étrange que NFS soit blâmé pour son manque de support pour inotify.
Network File System (NFS) est un protocole de système de fichiers distribué développé à l'origine par Sun Microsystems dans 1984, article de wikipédia
Cependant:
Inotify (inode notify) est un sous-système du noyau Linux {[11] } qui agit pour étendre les systèmes de fichiers afin de noter les modifications apportées au système de fichiers. [...] Il a été inclus dans le noyau Linux principal de la version 2.6.13 (juin 18, 2005 ) [...]. article de wikipédia
Il est difficile de s'attendre à ce qu'un protocole/application Réseau portable prenne en charge une fonctionnalité spécifique du noyau développée pour système d'exploitation différent et qui est apparu plus de vingt ans plus tard . Même si incluait des extensions pour cela, elles ne seraient pas disponibles ou utiles sur d'autres systèmes d'exploitation.
*l'accent est mis sur le mien dans tous les cas
Un autre problème avec ceci; supposons que nous n'utilisons pas du tout un 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 de bouclage; et le fichier sous-jacent est à son tour accessible à un emplacement différent dans le 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 sûr de le faire si le changement consiste à déposer du 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, alors qu'en même temps une montre inotify observe la même chose fichier sur le système de fichiers monté.
Il n'y a aucun moyen raisonnable de faire en sorte qu'inotify informe toujours le processus d'observation de ce genre de changement. Bien qu'il y ait probablement quelques girations qui pourraient être prises pour faire remarquer ext3 et honorer le changement, rien de tout cela ne s'appliquerait, disons, au drtiver xfs, qui est par ailleurs assez similaire.
Il ne devrait pas non plus. Vous êtes à la tricherie!. inotify ne peut vous informer que des modifications qui se sont produites via le vfs au point de montage réel regarder. Si les modifications se sont produites en dehors de ce VFS, en raison d'une modification des données sous-jacentes, inotify ne peut pas vous aider et n'est pas conçu pour résoudre ce problème.
Avez-vous envisagé d'utiliser une file d'attente de messages pour la notification réseau?
Je suis d'accord avec L'explication de SingleNegationElimination, et je voudrais ajouter que les cibles iSCSI fonctionneront, car elles alertent le noyau.
Donc, les choses sur les systèmes de fichiers "réels" (par rapport au système, c'est-à-dire) déclencheront Inotify pour alerter. Comme Rsync'ing, net-catting quelque chose dans une partition montée.
Si vous devez recevoir des notifications via inotify (ou utiliser inotify) vous pouvez faire un cron pour rsync -avz sur le système de fichiers. Les inconvénients sont que vous utilisez réel système hdd espace.
Pour tous ceux qui ont rencontré cette question dans la recherche d'une réponse à la question de savoir pourquoi le montage de bind sur Docker ne détectera pas les changements de fichiers du répertoire host (pour le rechargement à chaud d'une application), c'est parce que la propagation des changements de fichiers entre l'hôte et le conteneur n'est pas communiquée
Seules les modifications du conteneur lui-même sont communiquées au noyau. La Solution pour cela est de faire en sorte que votre utilitaire de rechargement en direct active le" mode d'interrogation " au lieu d'utiliser fsnotify.