inotify с помощью NFS

Question

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

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

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

Answer 1

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

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

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

Редактировать: Мне это кажется странным НФС следует винить в отсутствии поддержки inotify.

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

Однако:

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

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

_{*выделено мной во всех случаях}

---

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

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

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

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

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

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

Answer 2

Я нашел SGI Промежуток Использование демона супервизора для мониторинга модификации файлов. Он поддерживает NFS, и вы можете увидеть некоторое описание на вики

Answer 3

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

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

Answer 4

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

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

Если вы должны получить уведомления через INOTIFY (или необходимо использовать Inotify), вы можете сделать Cron rsync -avz в файловую систему. Недостатки, конечно, вы используете пространство для жесткого диска реального системы.

Answer 5

Я второй @singleneningelimination.

Кроме того, вы можете попробовать уведомление-экспедитор.

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

Если вы используете бродяга, используйте Vagrant-уведомление-экспедитор.