LINUX.ORG.RU

inotify


0

5

Суть такова: мне нужно мониторить довольно обширное дерево каталогов.
Отлавливать событие создания файла. Но при этом сначала создается вложенная структура и лишь потом записывается файл.
Что-то в духе:
/storage/1/
/storage/1/2/
/storage/1/2/3/
/storage/1/2/3/123456/
/storage/1/2/3/123456/file.ext

Вопрос: насколько для этого подходит inotify (в частности libinotifytools, который может мониторить рекурсивно)?
Файлов и каталогов будет очень много. Поскольку inotify на мониторинг каждого каталога открывает файловый дескриптор, то вопрос 2: какое максимальное значение открытых fd можно выставить через лимиты (гугл что-то не помог, сплошные статьи как увеличить, но верхний предел нигде не указан)?
Пример из libinotifytools натравленный на корень выдал при выставленном в 1000000 лимите «Not enough space on device»

★★★★

Если просто мониторить, то не проще ли в ядре покрутить, что б при open'е с O_CREAT, в dmesg сыпалось что-нибудь. И это уже выхватывать демоном?

Lego_12239 ★★ ()
Ответ на: комментарий от roy

Да-да, моё обсуждение :). Тогда пришёл к выводу что лучше inotify :). Я как раз и слежу за этой темкой чтобы узнать поменялось ли что в этой области.

true_admin ★★★★★ ()
Ответ на: комментарий от true_admin

А чем лучше? Документация какая-то тухлая совсем по fanotify(), но дескрипторов не создаёт, как я понял.

roy ★★★★★ ()
Ответ на: комментарий от roy

Лучше тем что оно работает, оно простое в использовании и все его используют.

Документация какая-то тухлая совсем по fanotify

Угу. Очень плохой знак.

true_admin ★★★★★ ()

Итак, погуглив, почитав lkml, потестив, проверил решение, если есть доступ к руту:

  1. Реальный каталог переименовываем, например, в /storage_real
  2. mount --bind /storage_real /storage
  3. Берём тестовую прогу. Добавляем в начало fanotify.c #define _LARGEFILE64_SOURCE
  4. запускаем от рута: fanotify -m /storage
  5. и смотрим, как создаются файлики во всех вложенных каталогах /storage.

Т.е. глобальный режим (FAN_MARK_MOUNT) для / был брут-форсом обойден через доп. mount.

gag ★★★★★ ()

And, I made it handle running out of inotify descriptors. By default, /proc/sys/fs/inotify/max_user_watches is 8192, and that's how many directories inotify can watch. Now when it needs more, it will print a nice message showing how to increase it with sysctl.

FWIW, DropBox also uses inotify and has the same limit. It seems to not tell the user how to fix it when it goes over. Here's what git annex watch will say:

Too many directories to watch! (Not watching ./dir4299) Increase the limit by running: echo fs.inotify.max_user_watches=81920 | sudo tee -a /etc/sysctl.conf; sudo sysctl -p

http://git-annex.branchable.com/design/assistant/blog/day_3__more_races/

fuxter ()
Ответ на: комментарий от iSage

Кстати, даже переименовывать не надо. Просто у меня «storage» ещё до mount был cwd, поэтому не сработало (надо было выйти и снова зайти cd ../storage).

gag ★★★★★ ()
Ответ на: комментарий от iSage

он и так маунт-поинт

Тогда и bind вообще не нужен.

gag ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.