Inotify с NFS - PullRequest
       7

Inotify с NFS

56 голосов
/ 20 ноября 2010

Я недавно создал систему Dropbox, используя inotify, наблюдая за файлами, созданными в определенном каталоге. Каталог, который я наблюдаю, монтируется с сервера NFS, а inotify ведет себя не так, как я ожидал. Рассмотрим следующий сценарий, в котором сценарий inotify запускается на компьютере A, просматривая / some / nfs / dir / также / visible / to / B.

-Используя машину A для создания файла в / some / nfs / dir / также / visible / to / B, скрипт ведет себя как положено. Используя компьютер B для выполнения того же действия, сценарий не уведомляется о новом файле, сброшенном в каталог.
-При запуске сценария на сервере NFS он получает уведомление, когда файлы создаются как на компьютере A, так и на компьютере B.

Это ошибка в пакете в пакете, который я использую для доступа к inotofy, или это ожидаемое поведение?

С уважением,

Andrew

Ответы [ 5 ]

66 голосов
/ 20 ноября 2010

inotify требует поддержки от ядра для работы.Когда приложение отслеживает каталог, оно просит ядро ​​сообщить ему, когда происходят эти изменения.Когда происходит изменение, в дополнение к записи этих изменений на диск, ядро ​​также уведомляет процесс наблюдения.

На удаленной машине NFS изменение не отображается ядру;это происходит полностью удаленно.NFS предшествует inotify, и в NFS нет никакой поддержки сетевого уровня или чего-либо подобного.

Если вы хотите обойти это, вы можете запустить службу на сервере хранилища (так как это ядро ​​всегда будет видеть изменения в файловой системе), которая брокерами будет отправлять запросы на удаленные машины и пересылать данные на удаленныеклиентов.

Редактировать: Мне кажется странным, что NFS следует обвинить в отсутствии поддержки inotify.

Сетевая файловая система (NFS) - это протокол распределенной файловой системы, первоначально разработанный Sun Microsystems в 1984 , статья в Википедии

Однако:

Inotify (уведомление inode) - это подсистема ядра Linux , которая расширяет файловые системы, чтобы замечать изменения в файловой системе.[...] Он был включен в основное ядро ​​Linux с версии 2.6.13 (18 июня, 2005 ) [...]. статья в википедии

Трудно ожидать, что портативный сетевой протокол / приложение будет поддерживать определенную функцию ядра, разработанную для другой операционной системы и появившуюся более двадцати лет спустя.Даже если в включены расширения для него, они не будут доступны или полезны для других операционных систем.

* выделение мин во всех случаях


Еще одна проблема с этим;Предположим, что мы вообще не используем сеть, а локальную файловую систему с хорошей поддержкой inotify: ext3 (предположим, она смонтирована в /mnt/foo).Но вместо реального диска файловая система монтируется с устройства обратной связи;и основной файл, в свою очередь, доступен в другом месте в vfs (скажем, /var/images/foo.img).

Теперь вы не должны изменять смонтированные файловые системы ext3, но это все еще достаточно безопасно, чтобы сделать этоесли изменение касается содержимого файла вместо метаданных.

Итак, предположим, что умный пользователь изменяет образ файловой системы (/var/images/foo.img) в шестнадцатеричном редакторе, заменяя содержимое файла некоторыми другими данными, оставаясь в то же времявремя, когда часы inotify наблюдают за тем же файлом в смонтированной файловой системе.

Нет разумного способа организовать уведомление, чтобы всегда информировать процесс наблюдения о такого рода изменениях.Несмотря на то, что, возможно, есть некоторые движения, которые можно предпринять, чтобы ext3 обратил внимание на изменения и выполнил их, ни одно из них не применимо, скажем, к xfs drtiver, который в остальном весьма похож.

И не должен.Вы обманываете!inotify может только информировать вас об изменениях, произошедших через vfs в фактической точке монтирования, которая отслеживаетсяЕсли изменения произошли за пределами этой VFS из-за изменения базовых данных, inotify не может вам помочь и не предназначен для решения этой проблемы.

Рассматривали ли вы использование очереди сообщений для сетевого уведомления?

6 голосов
/ 12 апреля 2013

Я нашел SGI FAM , использующий демон supervisor для мониторинга изменений файла.Он поддерживает NFS, и вы можете увидеть описание на wiki

2 голосов
/ 21 сентября 2018

Любой, кто сталкивался с этим вопросом в поиске ответа на вопрос, почему монтирование привязки в Docker не будет обнаруживать изменения файлов из каталога хоста (для горячей перезагрузки приложения), происходит потому, что распространение файлов между хостом иКонтейнер не передается в ядро ​​контейнера.

Только изменения самого контейнера передаются ядру.Решение этой проблемы состоит в том, чтобы ваша утилита прямой перезагрузки включила «режим опроса» вместо использования fsnotify.

0 голосов
/ 17 января 2019

I second @ SingleNegationElimination.

Кроме того, вы можете попробовать notify-forwarder .

  • Machine A отслеживает локальные события inotify, а затем пересылает их наМашина B (через UDP).
  • Машина B не (не умеет?) Воспроизводить события, но запускает событие ATTRIB для измененного файла.

Если вы используетеvagrant, используйте vagrant-notify-forwarder .

0 голосов
/ 31 мая 2016

Я согласен с объяснением SingleNegationElimination и хотел бы добавить, что цели iSCSI будут работать, поскольку они предупреждают ядро.

Таким образом, вещи в «реальных» файловых системах (то есть относительно системы) будут запускать Inotify для предупреждения. Как и Rsync'ing, что-то загружается в смонтированный раздел.

Если вам нужно получать уведомления через inotify (или использовать inotify), вы можете сделать cron для rsync -avz в файловой системе. Недостатки, конечно, в том, что вы используете настоящий системный жесткий диск.

...