инотифицировать с помощью NFS

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

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

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


person ajwood    schedule 20.11.2010    source источник
comment
То есть вы говорите, что только скрипт на сервере, которому принадлежит файловая система, или компьютер, который внес изменения, получает уведомление? Именно такого поведения я и ожидал.   -  person Gabe    schedule 20.11.2010
comment
Я сообщил о запросе функции здесь.   -  person HRJ    schedule 29.01.2013
comment
Я думаю, что этот вопрос можно переместить (перенести) на serverfault.com.   -  person F. Hauri    schedule 20.08.2019


Ответы (5)


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

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

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

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

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

Тем не мение:

Inotify (inode notify) — это подсистема ядра 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 не сможет вам помочь и не предназначен для решения этой проблемы.

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

person SingleNegationElimination    schedule 20.11.2010
comment
Это просто кажется ошибкой. Да, изменение сделано в другом месте, но дело в том, что клиенты NFS в конечном итоге обнаруживают новые добавленные файлы. Даже если событие было отложено, клиент NFS должен иметь возможность уведомлять слушателей inotify, когда он обнаруживает новые добавленные/удаленные ресурсы. - person James Blackburn; 25.02.2011
comment
@JamesBlackburn: это, вероятно, из соображений производительности. Клиенты NFS, вероятно, обнаруживают изменения только лениво, по запросу. - person static_rtti; 04.10.2012
comment
Конечно, NFS нельзя обвинить в том, что она не поддерживает inotify. Но ваш пример совершенно ошибочен. Реализация NFS может поддерживать что-то вроде inotify и может сопоставлять свой (внутренний протокол NFS) материал с материалом inotify. Это не. Так что, это - person Frunsi; 16.11.2012
comment
Мне нужно реализовать что-то подобное, но я не понимаю, как я буду использовать очереди сообщений для решения проблемы. Вы не против уточнить? У меня есть около 13-14 экземпляров разных (ВМ), каждый из которых обращается к подключенному NAS, и, поскольку inotify относится к ядру/ВМ, я сталкиваюсь с этой дилеммой. - person meder omuraliev; 20.02.2014
comment
@meder: это очень похоже на вопрос! - person SingleNegationElimination; 20.02.2014
comment
Предложение проксировать события inotify очень разумно, и существуют реализации: github.com/sillypog/inotify- прокси - person deed02392; 04.07.2017
comment
Может ли это работать в хранилище NAS, если оно смонтировано как каталог на сервере? - person Jaskaran Singh Puri; 25.07.2019
comment
Ваша последняя часть, сравнивающая nfs с loopback, на самом деле не является релевантной или точной аналогией. Общие ресурсы NFS предназначены для изменения несколькими системами. Протокол написан с учетом этого. Устройства Loopback не поддерживают прямую запись в базовый файл. Нет никакого кода, предназначенного для проверки устаревших страниц кэша, обновленных на диске. - person Philip Couling; 09.01.2021

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

person cmchao    schedule 12.04.2013
comment
Похоже, что для работы FAM требуется сервер FAM, работающий на удаленной ФС. Учитывая, что FAM даже старше, чем inotify, мне интересно, почему последний не поддерживает удаленную ФС. - person Wernight; 08.05.2014

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

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

person Derian Tungka    schedule 21.09.2018
comment
Да, и если вы пришли из мира Java, вот пример того, как это легко сделать с помощью apache-commons -› github.com/eugenp/tutorials/blob/master/core-java-io/src/main/ - person Dzmitry Hubin; 10.10.2018
comment
Может ли это работать в хранилище NAS, если оно смонтировано как каталог на сервере? - person Jaskaran Singh Puri; 25.07.2019
comment
На самом деле я только что попробовал это на хосте CentOS 7 и гостевом контейнере с Docker 18, и это сработало даже на томе хоста NFS. - person Doctor J; 28.08.2019
comment
В Docker нет такого понятия, как ядро ​​контейнера: есть только одно ядро, совместно используемое хостом и контейнером. Таким образом, inotify работает внутри контейнера, если используется при монтировании с привязкой из локальных файловых систем хоста. Но это не работает, если монтирование привязки относится к файловой системе NFS, где хост-докер является клиентом NFS, а файловая система изменена каким-либо другим клиентом NFS или непосредственно на сервере NFS. - person Juergen; 11.09.2020

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

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

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

person Richard Tang    schedule 30.05.2016

Я второй @SingleNegationElimination.

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

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

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

person jchook    schedule 17.01.2019
comment
Может ли это работать в хранилище NAS, если оно смонтировано как каталог на сервере? - person Jaskaran Singh Puri; 25.07.2019
comment
@JaskaranSinghPuri inotify работает на уровне VFS ядра, поэтому я думаю, что вы увидите файловые операции, выполняемые на машине, на которой работает inotifywait, но не операции, выполняемые на другом удаленном клиенте. - person jchook; 26.07.2019