Комментарии 34
Ну, если Вы уже в тэгах упомянули inotify, то надо было посвятить нас — чем он Вас не устроил? Особенно в свете существования incron'а.
Мне также нужна поддержка FreeBSD, я написал об этом.
Ну так механизм inotify там в полной красе. А вот incron'а увы нету…
Насколько мне известно, на фре вместо inotify используется kqueue.
kqueue это конечно да, Но мне казалось, что inotify из Linux там тоже присутствует.
нет конечно. зачем? inotify это нашлёпка в ядро Linux. kqueue это базовая функциональность FreeBSD. зачем ему нашлёпка inotify?
Да вот, сейчас искал так и не нашёл. Странно, откуда у меня это ощущение, что видел я во фре inotify :-( Постараемся больше смуту не вносить.
У Inotify:
Гораздо выше лимит на кол-во отслеживаемых файлов
Нет проблем с отмонтированием ФС на которых отслеживаются файлы (если поставить следилку на файл а потом попытаться отмонтировать этот раздел, то ничего не выйдет)
Гораздо выше лимит на кол-во отслеживаемых файлов
Нет проблем с отмонтированием ФС на которых отслеживаются файлы (если поставить следилку на файл а потом попытаться отмонтировать этот раздел, то ничего не выйдет)
нет там лимита. там немного удобнее тем, что в каталоге inotify будет давать нотификацию по всем файлам, не беря отдельно. зато там долгие годы были иные проблемы.
с монтированием да — придётся ловить отдельно
с монтированием да — придётся ловить отдельно
Нет лимита? 1024 же по умолчанию лимит на кол-во файловых дескрипторов. Да, можно увеличить, но не всегда.
Где такой лимит?
packages.python.org/watchdog/installation.html#dependencies
BSD variants come with kqueue which programs can use to monitor changes to open file descriptors. Because of the way kqueue(2) works, watchdog needs to open these files and directories in read-only non-blocking mode and keep books about them.
watchdog will automatically open file descriptors for all new files/directories created and close those for which are deleted.
The maximum number of open file descriptor per process limit on your operating system can hinder watchdog‘s ability to monitor files.
BSD variants come with kqueue which programs can use to monitor changes to open file descriptors. Because of the way kqueue(2) works, watchdog needs to open these files and directories in read-only non-blocking mode and keep books about them.
watchdog will automatically open file descriptors for all new files/directories created and close those for which are deleted.
The maximum number of open file descriptor per process limit on your operating system can hinder watchdog‘s ability to monitor files.
Еще момент вспомнил про KQueue чисто субъективный — довольно сложно было найти хорошую документацию/примеры/хауту по слежению за файлами через KQueue.
Просто где ни читаешь — на Windows RDCW, примеры, описания, на Linux Inotify + примеры, описания. А про FreeBSD в лучшем случае напишут «аналогом Inotify на FreeBSD является KQueue» и ни примера ни подробностей. Т.е. о такой функциональности в принципе слышали, но никто ее не видел. Когда разберешься, то уже все просто, но в начале даже непонятно: «работает ли это на практике или просто для галочки, а если и работает то почему так трудно найти примеры, наверное криво работает рас никто не пользуется». Да и если гуглить KQueue то в основном про слежение за сокетами пишут.
Просто где ни читаешь — на Windows RDCW, примеры, описания, на Linux Inotify + примеры, описания. А про FreeBSD в лучшем случае напишут «аналогом Inotify на FreeBSD является KQueue» и ни примера ни подробностей. Т.е. о такой функциональности в принципе слышали, но никто ее не видел. Когда разберешься, то уже все просто, но в начале даже непонятно: «работает ли это на практике или просто для галочки, а если и работает то почему так трудно найти примеры, наверное криво работает рас никто не пользуется». Да и если гуглить KQueue то в основном про слежение за сокетами пишут.
Есть эмуляция INotify на KQueue github.com/dmatveev/libinotify-kqueue
НЛО прилетело и опубликовало эту надпись здесь
Имел опыт написания асинхронной следилки под MacOS, Windows и Linux на Python (Twisted)…
Задача была отслеживать рекурсивно каталог и все изменения в нем. При этом, по возможности, обойтись без отдельного треда (т.е. следить в EventLoop Twisted-а).
По легкости написания:
Windows самый простой O_o (ReadDirectoryChangesW + WaitForMultipleEvents) Опционально асинхронное, поддерживает все события, рекурсию, переименования. Для слежения навешивается обработчик на отслеживаемый корневой каталог.
Linux посерединке (Inotify) Опционально асинхронное, поддерживает все события, но не поддерживает рекурсию и переименование (только через механизм «Cookies»). Для слежения навешивается обработчик на отслеживаемый корневой каталог и все его дочерние каталоги.
MacOS самый геморройный (Kqueue) — Асинхронное, поддерживает все события (вроде), не поддерживает рекурсию, переименования (засчитывается как удаление и создание). Для слежения навешивается обработчик на отслеживаемый корневой каталог и все его дочерние каталоги и НА ВСЕ ФАЙЛЫ, если файлов больше 1024 нужно лезть в ulimit. Ну и желательно иметь в памяти слепок структуры каталогов, чтобы отслеживать переименования. На FreeBSD все точно так же, но есть проблема с отмонтированием ФС на которых следят. На MacOS есть еще механизм FSEvents, но у него не нашел асинхронного варианта.
Задача была отслеживать рекурсивно каталог и все изменения в нем. При этом, по возможности, обойтись без отдельного треда (т.е. следить в EventLoop Twisted-а).
По легкости написания:
Windows самый простой O_o (ReadDirectoryChangesW + WaitForMultipleEvents) Опционально асинхронное, поддерживает все события, рекурсию, переименования. Для слежения навешивается обработчик на отслеживаемый корневой каталог.
Linux посерединке (Inotify) Опционально асинхронное, поддерживает все события, но не поддерживает рекурсию и переименование (только через механизм «Cookies»). Для слежения навешивается обработчик на отслеживаемый корневой каталог и все его дочерние каталоги.
MacOS самый геморройный (Kqueue) — Асинхронное, поддерживает все события (вроде), не поддерживает рекурсию, переименования (засчитывается как удаление и создание). Для слежения навешивается обработчик на отслеживаемый корневой каталог и все его дочерние каталоги и НА ВСЕ ФАЙЛЫ, если файлов больше 1024 нужно лезть в ulimit. Ну и желательно иметь в памяти слепок структуры каталогов, чтобы отслеживать переименования. На FreeBSD все точно так же, но есть проблема с отмонтированием ФС на которых следят. На MacOS есть еще механизм FSEvents, но у него не нашел асинхронного варианта.
можно еще использовать rsync для мониторинга изменений удаленно, прикрутить к крону или подобному скрипту, вызывать из java и тому прочее… вот, в целом отличная статья, небольшая и полезная!
Целевым обработчиком событий в ФС является все тот же python, который предпринимает некоторые действия. Чем меньше внешних вызовов, тем лучше.
А rsync показывает не самую высокую производительность на большом числе файлов и нагруженных дисках… Как раз те условия, где будет использоваться система с python.
А rsync показывает не самую высокую производительность на большом числе файлов и нагруженных дисках… Как раз те условия, где будет использоваться система с python.
А чем aide не устроила?
Во FreeBSD есть mtree.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мониторинг за изменениями файловой системы