Инженер, PHP, Go, Linux
13,9
рейтинг
5 января 2013 в 16:11

Администрирование → Слежение за изменениями в директории: как это делается в разных ОС

Я бы хотел посвятить статью обзору API, предоставляемых разными ОС для слежения за изменениями в директории. Статья появилась как результат моей работы над демонами слежения за изменениями для утилиты dklab_realsync (статья на хабре, github репозиторий) и своей собственной, которую я пока что не хочу анонсировать.

Windows, ReadDirectoryChangesW


Для операционной системы Windows есть замечательная функция ReadDirectoryChangesW, которая возвращает набор изменений для директории, в том числе содержит флаг для работы рекурсивно (bWatchSubtree). Таким образом, реализация слежения за изменениями в директории не представляет особого труда и в том же dklab_realsync реализация занимает 80 строк кода или 3.5 Кб. Интересно, что в Windows эти события поддерживаются даже через SMB!

Тем не менее, существуют определенные подводные камни:

  • конечный размер буфера изменений, после которого очередь событий переполнится и эти события будут потеряны
  • согласно документации к watchdog package, событие перемещения посылается раньше, чем изменения становятся видны в ФС
  • размер буфера ограничен в 64 Кб для сетевой ФС


Вывод: Функция ReadDirectoryChangesW позволяет легко узнавать обо всех событиях в файлах, но, очередь событий может переполниться и тогда нужно будет выполнять полное сканирование ФС. Также, возможна доставка событий до того, как они станут актуальны.

Mac OS X, FSEvents


В Mac OS X также есть удобный и простой API для слежения за изменениями в файловой системе под названием FSEvents. С использованием этого API простейшая реализация демона составляет 50 строк кода или 1.8 кб. Очередь не может переполниться (!), но полное сканирование все же может потребоваться, если демон fseventsd «упадет». Стоит отметить, что этот API до версии 10.7 не предоставляет изменения по файлам, он сообщает только директории, в которых что-то изменилось. Поскольку события никуда не деваются и пишутся в лог (FSEvents service stores events in a persistent, per-volume database), детализация с точностью для директории позволяет сэкономить место на диске.

Вывод: FSEvents API для Mac OS X является самым необычным из всех подобных API. Очередь не переполняется и даже имеется возможность получить события из прошлого. Тем не менее, детализация событий дается с точностью до директории (до версии 10.7), что означает меньшую эффективность демона для синхронизации файлов.

Linux, inotify


В linux vanilla kernel существует один способ слежения за изменениями в директории — это inotify. Для этого API существует хорошая и подробная документация, но нет поддержки рекурсивного слежения за изменениями! Также, у inotify есть ограничение на максимальное количество объектов, за которыми можно следить. Простейшая реализация демона занимает уже 250 строк кода или 8 кб. Статическая сборка с использованием dietlibc занимает примерно 14 кб. Другим неприятным моментом является то, что приложение должно само поддерживать соответствия между watch descriptor (в нашем случае это всегда директория) и именем. Есть функция inotify_add_watch, которой передается путь до отслеживаемой директории, но нет обратной — inotify_get_path, которая бы возвращала этот самый путь по переданному дескриптору. События же содержат только watch descriptor и относительный путь до изменившегося файла внутри директории.

Подводные камни рекурсивного слежения за директорией через inotify:

  • Возможность переполнения очереди (длина очереди задается в /proc/sys/fs/inotify/max_queued_events)
  • Ограничение на максимальное количество объектов слежения (задается в /proc/sys/fs/inotify/max_user_watches)
  • Отсутствие возможности рекурсивного слежения за директорией
  • Необходимость отдельно обрабатывать случай, когда создается директория (например mkdir -p a/b/c). Вы получите событие о том, что создана директория «a», но пока вы навешиваете обработчик на эту директорию, в ней уже могут создать ещё одну директорию и событие об этом вам уже не придет.
  • Теоретическая возможность целочисленного переполнения watch descriptor (wd), так как он задается uint32


FreeBSD, Mac OS X, kqueue


FreeBSD и Mac OS X позволяют отслеживать за изменениями с помощью kqueue, который аналогичен inotify по своим характеристикам и также не имеет возможности рекурсивного слежения за директориями. Также, kqueue принимает в качестве аргументов дескрипторы открытых файлов (директорий), поэтому при использовании этого API ограничения на количество отслеживаемых директорий ещё более строгие.

Итого:


Механизм Переполнение очереди Рекурсивный? Макс. объектов Детализация
ReadDirectoryChangesW Да Да файл
FSEvents Нет Да файл (10.7+)
inotify Да Нет 8192 файл
kqueue Да Нет 1024 файл
Как можно видеть, у всех API существуют свои достоинства и недостатки. Наименее удобными являются механизмы kqueue и inotify, но они же являются самыми эффективными и надежными. Коммерческие ОС предоставляют более удобные механизмы слежения за изменениями, но у них тоже есть свои особенности. Надеюсь, теперь вы имеете больше представления о том, как тяжела участь Dropbox и подобных программ, которым требуется со всем этим уживаться и осуществлять надежную и эффективную синхронизацию данных :).

* Картинка взята с www.alexblogger.com/2008_01_01_archive.html
Юрий Насретдинов @youROCK
карма
237,1
рейтинг 13,9
Инженер, PHP, Go, Linux
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (75)

  • +3
    По сути ссылками на исходники ты анонсировал утилиту, которую не хочешь пока анонсировать?=)
    • 0
      dklab_realsync?
      Она описывалась автором на Хабре: habrahabr.ru/post/139348/
      ☃­
      Я ею пользовался с тех самых пор около полугода, пока она вдруг не перестала работать через rsync по неясным мне причинам — запускалась где-то раза с пятого. Пришлось даже осилить Perl, чтобы заменить rsync на robocopy — настолько я привык к автоматической синхронизации изменений :) А затем я вдруг узнал, что моя IDE умеет делать такое «искаропки» :)
      • 0
        Вы все-все ссылки на исходники открывали? =) realsync-ом и я пользуюсь уже давно.
  • +6
    как тяжела участь Dropbox и подобных программ, которым требуется со всем этим уживаться
    В питоне же вроде был платформонезависимый интерфейс для слежения за файлами?

    И да: почему пример для Windows — на C++, а для остальных ОС — на C? И что вы имеете в виду под «простейшей реализацией», что должны уметь? В той же версии для MacOs я не увидел никаких проверок на ошибки инициализации, коих полно в linux-версии. И гугл находит более простые версии для работы с inotify
    • +3
      В питоне же вроде был платформонезависимый интерфейс для слежения за файлами?

      Честно скажу — я не пользовался этим API. В любом случае, любые платформонезависимые интерфейсы будут всё равно пользоваться описанными мной API с соответствующими недостатками.
      И да: почему пример для Windows — на C++, а для остальных ОС — на C?

      Несмотря на расширение cpp, для windows код тоже на чистом Си.
      И что вы имеете в виду под «простейшей реализацией», что должны уметь?

      Непрерывно уведомлять обо всех изменениях содержимого файлов в отслеживаемой директории, с изменениями во всех вложенных директориях.
    • 0
      В той же версии для MacOs я не увидел никаких проверок на ошибки инициализации

      Согласен, но это добавит ещё строк 10 к реализации. Остальное необходимо для реализации рекурсивного отслеживания за директорией.

      И гугл находит более простые версии для работы с inotify

      Вы уверены, что они позволяют рекурсивно отслеживать изменения в директории, не пропуская при этом события?
      • 0
        Вы уверены, что они позволяют рекурсивно отслеживать изменения в директории, не пропуская при этом события?

        Самому стало интересно, сейчас более подробно посмотрю и отпишусь :)
        • +1
          Мда, похоже действительно всё так печально.

          Вот, как это сделано в inotifytools, авось пригодится: github.com/rvoicilas/inotify-tools/blob/master/libinotifytools/src/inotifytools.c#L1290
          • +1
            Цитата из мана ( linux.die.net/man/1/inotifywatch ):

            Bugs

            There are race conditions in the recursive directory watching code which can cause events to be missed if they occur in a directory immediately after that directory is created. This is probably not fixable.
            It is assumed the inotify event queue will never overflow.


            Такая реализация вообще никуда не годится, уж извините.
            • +1
              This is probably not fixable.

              Те есть просканировать директорию после начала слежения разработчики догадываются не могут…
              • 0
                Вообще они странные ребята, если честно… Почему они ничего не делают в случае переполнения очереди тоже не очень понятно. Ну и строки в исходниках немного странноватые:
                fprintf(stderr, "Inotify reported end-of-file.  Possibly too many "
                		                "events occurred at once.\n"); // что значит "possibly"..? что мешало заглянуть в документацию?
                ...
                niceassert( first_byte <= bytes, "ridiculously long filename, things will "
                	                                 "almost certainly screw up." );
                ...
                niceassert( (long)((char *)&event[0] +
                			            sizeof(struct inotify_event) +
                			            event[0].len) <= (long)ret,
                			            "extremely unlucky user, death imminent" );


                Поэтому я решил написать свою версию, которая не будет иметь зависимостей и будет работать адекватно в случае проблем :).
    • 0
      Dropbox на Linux использует inotify. Вот, например.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Ну и ссылку на сам класс приложу: QFileSystemWatcher.
        • 0
          Увы, но QFileSystemWatcher только сообщает о факте изменения файла/директории, а вот уточнять не хочет. Если нужно получать имена создаваемых файлов, стандартные средства Qt не работают :(
  • +1
    FSEvents предоствляет изменения по файлам начиная с OSX 10.7.
    • +1
      Вот здесь есть информация о том, как это использовать: developer.apple.com/library/mac/#documentation/Darwin/Reference/FSEvents_Ref/Reference/reference.html

      А здесь — пример: github.com/joyent/libuv/blob/master/src/unix/fsevents.c#L234
      • 0
        Спасибо, не знал, что в Lion уже появился соответствующий API. Сейчас обновлю статью.
      • +6
        Вы уверены, что получения изменений по файлам появилась только в OSX 10.7?

        Насколько я знаю, это ограничение именно обертки, т.е. демона fseventsd и, как следствие, FSEventStreamCreate, который к нему обращается.

        Ведь если обращаться напрямую к kernel API через /dev/fsevents, то все можно отслеживать еще в 10.4 (когда и появился Спотлайт); пример: fslogger.c из во многом устаревшей, но хорошей книги Mac OS X Internals: a System Approach, см. главу 11.8, где рассказано про спотлайт и fsevents (+ маленькая заметка есть и на сайте). Вместе с тем — это было private undocumented API, тот же fslogger без правок на новых версиях не соберется.

        Чтобы избежать переполнения буфера, перестать потенциально мешать основному потребителю /etc/fsevents — Спотлайту, уйти от рут-привилегий и консолидировать изменения, в 10.5 появился демон fseventsd (Advanced Mac OS X Programming: The Big Nerd Ranch Guide, глава 16, про kqeue и fsevents).

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

        API /etc/fsevents вроде как стало паблик, но вряд ли надолго, потому что у него всего три потребителя: coreserviced, mds (Spotlight) и fsevents, через который и реализован FSEvents из CoreFoundation.

        Тем не менее, есть пример низкоуровневого обращения к fsevents, работающий и в последних версиях (обращение идет через /dev/fsevents; требует root privs): filemon.c) — у меня нормально работает в Mountain Lion (взято из главы 3, раздел про FSEvents, книга Mac OS X and iOS Internals: To the Apple's Core).

        Правильнее, конечно, в 99% случаев пользоваться официальным интерфейсом, Вы правы. Просто как раз читаю последнюю из упомянутых книг, не мог не упомянуть, что вопрос куда интереснее, чем кажется :)
        • 0
          Я имел в виду API, а не возможности системы.
        • 0
          Пользоваться интерфейсом правильно в 100% случаев, поскольку даже минорные обновления операционной системы могут поломать ваше приложение.
          • +1
            Бывает, что на риск (и соответственно готовность к обновлениям под каждый минорный релиз) идут осознанно. Пример — Total Finder, Glims, MailTags… уверен, что кому-то и без fsevents жизнь была не жизнь. Я, в целом, не спорю, просто дополнил Ваш комментарий дополнительной информацией.
    • 0
      FSEvents оказались довольно неудачными.
      Во-первых, при старте слежения «начиная с сейчас», может прислать события из прошлого.
      Во-вторых, очень неудачно объединяет события. Часто из маски невозможно выяснить, в каком порядке произошли события. Например, файл был создан, а потом удалён, или наоборот.
      И, наконец, до сих пор по этим «новым» флагам, добавленным в 10.7, нет никакой внятной документации, кроме простого перечня флагов.
      • 0
        Поэтому надо всё определять самим :)
  • 0
    Я в django проектах недавно начал пользоваться функционалом uwsgi еще и для слежения за изменениями в папке.
    Может кому-то пригодится если проект деплоится через uwsgi тут документация.
  • +2
    Обрабатывает ли dklab_realsync случаи когда у одна файловая система case-preserving, case-insensitive а другая case-sensitive? Как на счёт Unicode normalization (NFC, NFD, Mac-NFD) у имён файлов? Как на счёт случая когда на одной машине одна файловая система case-sensitive, а в её сабдиректорию примонтирована case-insensitive.
    Как на счёт точек в конце имени файла, или прочих символов — www.dropbox.com/help/145/en?
    • +1
      dklab_realsync не является конкурентом dropbox, потому что dklab_realsync осуществляет одностороннюю синхронизацию. Насколько я знаю, ответ на все ваши вопросы — нет, ничего из этого не учитывается. Это не должно представлять большой проблемы при целевом её использовании — синхронизации файлов в веб-проекте с локального компьютера на *nix-сервер.
      • +1
        Ну ок, а то я думал если поддерживает, то обменяться опытом, у меня тоже проект есть где важны имена файлов, думаю как это всё реализовать…
      • +1
        Вообще, только то что типичный случай здесь — веб разработка, оправдывает игнорировыние проблемы :)
        То что синхронизация в одно сторону, и целевой сервер — *nix особо ничего не меняет.

        Например если у нас есть директория public/München, в которой 1000 файлов,
        он отправлена в git на линуксе, затем получена в git на MacOSX, затем с обоих машин происходит
        синхронизация на веб сервер, то во первый Linux будет создавать директорию со строкой «M\x{fc}nchen», macosx будет создавать «Mu\x{308}nchen» (выглядит на экране часто как «Munchen»). При этом они это будут делать по-очереди, в результате будет DDoS.
        Так же если сервер под Linux, он не найдёт «M\x{fc}nchen»

        Кстати мой проект тоже на perl, опубликован здесь habrahabr.ru/post/150324/ но с именами файлов по большей части ничего почти не реализовано, пока.
        • +1
          DDoS не будет, потому что синхронизация тригается после локальных изменений, т.е. пройдёт две синхронизации — с OS X и Linux, и победит тот, кто был последним, или же у вас на сервере окажутся две директории — «M\x{fc}nchen» и «Mu\x{308}nchen».
  • +1
    В Windows на NTFS и ReFS ещё можно просматривать журнал USN, а там есть все последние операции с файлами.
    • 0
      Честно говоря, я не знаю, насколько realtime будут такие события, поэтому не стал об этом ничего писать. Но, возможно, этот API тоже может решить проблему потери событий.
      • +1
        Просмотр всего журнала довольно быстрая операция, по идее. Вот здесь с помощью USN-журнала реализовали мгновенный поиск файлов в Windows (на самом деле мгновенный поиск по части файлов). Все последние операции с файлами там конечно сразу появляются, но вот если операций очень много, журнал может и переполниться. Я своей программой NTFS Stream Explorer полазил по системе, и очень часто встречается ситуация, что USN-идентификатор файла указывает на запись в журнале, которая относится к совсем другому файлу. То есть с тех пор как был изменён старый файл, журнал уже переполнялся и записи были перезаписаны.
      • 0
        OSX-овые FSEvents — это как раз аналог виндового USN Journals, а не ReadDirectoryChanges.
  • 0
    Писал кроссплатформенную следилку за изменениями директорий когда работал в freebrie.net/ (a-la p2p дропбокс)
    Делалось на Python на базе Twisted. Ну и было важное ограничение — нужно чтобы следилка работала в неблокирующем режиме.

    В Windows всё просто было — ReadDirectoryChangesW + WaitForMultipleObjects (??). Из плюсов — автоматически обрабатывает переименования; поддерживает рекурсивное отслеживание (это очень сильно всё упрощает). Минусов что-то даже не припомню.
    В Linux — inotify. Из плюсов — довольно удобное API, много опций, практически неограниченное кол-во одновременно отслеживаемых директорий (~60000). Переименовывание отслеживается полуавтоматически (через cookie). Из минусов — нет поддержки рекурсии (как описано в статье). Навешиваешь следилку на дерикторию и оно сообщает если что-то изменилось непосредственно в этой директории, но не во вложенных. В целом жить можно =)

    Самый геморрой был с MacOS. Для fsnotify не удалось найти неблокирующего API (для python по крайней мере), так что решили взять kqueue. Прикол в том, что в kqueue нельзя навесить следилку только на директорию. Нужно навешивать её НА КАЖДЫЙ ФАЙЛ. Если навесить на директорию, то будут видны только изменения, при которых что-то вносится в «файл директории» (удаление/добавление файла). А лимит на количество открытых файлов обычно выставлен в 1024 файла.

    Ну и во всех случаях желательно иметь полный снимок структуры отслеживаемого дерева файлов и фоллбек в виде периодического полного сканирования структуры ФС.
    Кому интересно — можете посмотреть как в UbuntuOne реализовано слежение под Linux Windows и Mac

    • 0
      Про Mac OS X — вы фактически цитируете причины, по которым в 10.4 появились самостоятельные механизмы отслеживания, без kqueue ) Там ведь еще есть проблемы с иерархией, в том числе, когда надо все вешать отслеживание на все вновь появляющиеся подкаталоги и файлы — а ведь сверху все ограничено лимитом открытых файлов… Я не пишу на python, но все же стоит попробовать найти что-то необлокирующее со словом FSEvents, механизму — годы, не может не быть обертки.
    • 0
      В случае kqueue не просто видны удаления и добавления файлов, а видны факты таких событий. Просто так получить имена этих файлов не получится :(
      • 0
        При навешивании на fd директории? Да, нужно делать дифф содержимого директории до и после события, т.е. хранить всегда где-то список содержимого.
  • –1
    Я, может, не в тему, но — по поводу кода реализации на Windows — если уж ручками SubSystem
    #pragma comment(linker, "/SUBSYSTEM:console")
    
    указан, так и Character Set — скажите, что не Unicode :)
    #undef UNICODE
    #undef _UNICODE
    
    • –1
      Конкретно для Windows реализацию писал не я, а Дмитрий Котеров (DmitryKoterov), поэтому ничего ответить про особенности реализации не могу.
  • +2
    А вы не думали использовать готовые кросс-платформенные решения? Например, libuv
    • +1
      Думал. Есть API для слежения за директориями в Glib, wxWidgets и т.д., но я не хочу для утилиты синхронизации файлов тащить библиотеки в много мегабайт. Поэтому, например, для linux мне в итоге пришлось написать свою реализацию с нуля, с корректной обработкой всех ошибок.
  • 0
    Я просто оставлю это здесь github.com/guard/guard.
    • –1
      Интересно, хоть и на ruby, спасибо.
      • 0
        Какая разница на чём?
        • –1
          Остальная часть моей утилиты на PHP. Демон уведомлений о файловой системе на Ruby и демон синхронизации файлов на PHP выглядит немного странно :).
          • 0
            Я понимаю зачем вам вообще демон. Тем более на PHP. Просто заливать рсинком те файлы что изменились да и все.

            Для гарда есть вагон плагинов на все случаи жизни.
            • 0
              Rsync через ssh может давать весьма ощутимую задержку в несколько секунд при соединении с сервером, если сервер находится довольно далеко. Написание простенького демона, который может один раз установить соединение и в дальнейшем слушать события ФС и заливать файлы (как это делает realsync) дает намного лучшую latency. Это уже обсуждалось в статье на хабре про dklab_realsync ( habrahabr.ru/post/139348/ ), хотя Дима Котеров приводит другую причину — это медленная работа rsync под windows.
              • +1
                Rsync через ssh может давать весьма ощутимую задержку в несколько секунд при соединении с сервером, если сервер находится довольно далеко.
                Учите матчасть. В ssh есть вещь называемая ControlMaster, которая как раз и позволят устанавливать одно соединение и реиспользовать его.

                Про медленный рсинк не верю. Где цифры?
                • 0
                  Видимо, Вы упустили, что речь идет о rsync через ssh. Попробуйте сравнить копирование одного (большого) файла при помощи scp и, скажем, того же «голого» rsync'а. И ControlMaster тут совсем не причем. Шифрование прогоняет данные через CPU — вот и вся причина, тогда как простая отправка данных с HDD в сеть может происходить вообще без его участия, что гораздо быстрее. Более того, в рамках ssh скорость сильно зависит от используемого блокшифратора, arcfour самый быстрый.
                  • 0
                    Ой, да ладно вам. Вот отличная тема для новой статьи: что быстрее самопальный велик или rsync over ssh?
                    • 0
                      Про велик ничего сказать не могу, но rsync+ssh будет работать медленней, чем просто rsync. Я только об этом.
                      • +1
                        Ну при передаче по сети всё равно должен быть какой-то медиум. В случае, если вы инициируете подключение это чаще всего ssh. Надо будет попрыгать с бубном на досуге и подобрать самый быстрый протокол.
                        • 0
                          finger же.
                      • 0
                        Что_угодно over ssh будет работать медленнее, чем просто что_угодно. Это, очевидно, связано с тем, что каждый пакет оборачивается на источнике и разворачивается на приемнике. Еще что_угодно over ssh будет на маленьких пакетах жрать в разы больше траффика.
                        Только при чем тут это?
                        • 0
                          Абсолютно не при чем см. ПС :)
                    • 0
                      Ладно. Последняя попытка убедить вас в том, что эта вещь не делается с помощью rsync.
                      Какую вы предлагаете использовать реализацию для того, чтобы обеспечивать (пускай одностороннюю, хотя я хочу двухсторонюю, что более-менее реализуется с помощью unison)?
                      Я полагаю, раз вы рассуждаете о ненужности событий ФС, вы предлагаете использовать что-то вроде
                      while true; do rsync $dir $host:$dir; done


                      Таким образом, мы получим 100% утилизацию одного ядра в системе. Например, в моем компьютере их всего 2… Помимо этого, возможно вы слышали про такую вещь, как ноутбуки. И они начинают греться и шуметь вентиляторами, как правило, даже при загрузке одного ядра на 100%.

                      И тут почему-то решение с событиями ФС уже не такое глупое и ненужное, неправда ли?
                      • 0
                        К сожалению я имею ввиду не циклический рсинк, а запуск рсинка по событию в фс, что обеспечивает гард и его плагин guard-process в частности.
                        • 0
                          В таком случае есть и другие готовые решения, например lsyncd. Но вот только они все обеспечивают более-менее реалтаймовую синхронизацию в одном направлении. Я же хочу иметь двухсторонюю синхронизацию, причём сразу на много серверов. Поэтому хоть и это и велосипед, но всё остальное работает не лучше.
                          • 0
                            Я постараюсь сделать замеры и привести вам аргументы в пользу того, что в случае изменения одного файла послать один пакет быстрее, чем послать и принять stat от всех файлов :), если это для вас ещё не очевидно.
                            • 0
                              Мля, а rsync'y низя передать список изменённых файлов? :)
                              • 0
                                Вы меня не слышите (и не слушаете). Повторю ещё раз:

                                1. Если бы я делал исключительно однонаправленную синхронизацию, я согласен, можно было бы поспорить по поводу того, что rsync здесь плохо подходит (на самом деле он очень хорош при отсутствии обратной связи с сервера)
                                2. Мне нужна двунаправленная (!) синхронизация на много серверов одновременно, значит вместо rsync нужно уже использовать unison
                                3. Чтобы unison мог коннектиться «обратно» к моей машине, нужно создавать обратные тоннели или создавать другие костыли. К тому же, под windows пришлось бы вообще заставлять пользователя поднимать ssh-сервер, что мне кажется весьма неправильным.
                                4. Просто с помощью rsync я не могу контролировать, что именно отсылается на другую сторону, поскольку rsync не печатает stat() от посланных файлов. Мне же важно, что именно было отправлено, поскольку мне нужно как-то контролировать то, что я не вызываю rsync/unison и тд в цикле, т.к. синхронизация изменений с локальной машины вызовет цепочку событий на удаленной машине, которые в свою очередь… ну вы поняли.
                                • 0
                                  Я уже понял, что все велосипеды оправдываются двунаправленной синхронизацией. Удачи вам.
                                  • 0
                                    Спасибо
                      • +2
                        События это ок. Отдельный велосипед нет.
                        • +1
                          На любом линуксе при установке пакета dropbox четко видно, что он тянет за собой rsync. Наверняка в дропбоксе сидят глупые ребята, они не умеют писать собственные велосипеды.

                          ;-)
                • 0
                  Вы уверены? Судя по ману и отзывам в сети, это поможет если делается несколько одновременных соединений. А тут обсуждается случай, когда идут последовательные соединения.
                  • 0
                    Безусловно, ControlMaster помогает ускорить трансфер при нескольких одновременных соединениях. Я написал лишь, что ssh в принципе медленнее, чем «голый» TCP.

                    ПС. Перечитал всю ветку, и понял, что все, включая меня, дискутируют о разных проблемах. Каждый о своем… )
                    • 0
                      Ага :)
  • 0
    Я правильно понимаю, что на inotify на каждый следимый файл открывает по десктриптору? Или только на директорию? Если на каждый файл, то 65k это как-то мало очень.
    • 0
      Для слежения с помощью inotify достаточно открывать только директории, причём он не требуется делать open(), декскрипторы получаются с помощью inotify_add_watch. Вот только откуда вы взяли 65k, по умолчанию max_user_watches составляет всего 8192 (директории).
      • +1
        $ cat /proc/sys/fs/inotify/max_user_watches
        65536

        opensuse 12.2, свежеустановленная, ничего не трогал. Ядро 3.4.11

  • +1
    На ядрах linux, начиная с 3.6.26 есть fanotify, который должен будет заменить inotify. Этот механизм пока еще плохо документирован ( www.spinics.net/lists/linux-man/msg02302.html, lwn.net/Articles/360955/). Пишут, что также можно блокировать вызов open() и в user space давать разрешение на открытие файла.
    • 0
      Насколько я смог понять из скудной информации в интернете насчёт fanotify, он именно из-за его постоянных обращений в userspace является, прямо скажем, неоптимальным, поэтому на него забили и больше не развивают :). А жаль, выглядит интересно.
  • 0
    На эту же тему я делал описание либы для Python, работающей на win/bsd/linux/mac.
    Собственно, там в исходниках весьма доходчиво все расписано, как под каждую платформу сделано :)

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.