https://www.opennet.me/openforum/vsluhforumID3/112773.html После более года разработки доступен (http://ghostbsd.org/11.1_release_announcement) релиз десктоп-ориентированного дистрибутива GhostBSD 11.1 (http://ghostbsd.org/), построенного на базе FreeBSD 11.1 (https://www.opennet.ru/opennews/art.shtml?num=46920) и предлагающего пользовательские окружения Xfce и MATE. Поддерживается как работа в Live-режиме, так и установка на жесткий диск (используется собственный инсталлятор ginstall, написанный на языке Python). Загрузочные образы сформированы (http://www.ghostbsd.org/download) для архитектуры amd64 (2 Гб).<br><br><br><br><br><br>Особенности выпуска:<br><br><br>- Прекращены формирование 32-разрядных сборок и поддержка архитектуры i386;<br>- Введён в строй собственных репозиторий с приложениями (раньше использовался штатный репозиторий бинарных пакетов FreeBSD);<br>- Добавлены средства для выполнения в гостевых системах под управлением VMware Workstation;<br>- В инсталлятор добавлены опции для зеркалирования дисков, манипуляций с MBR и GPT и настройки раздела подкачки;<br>- В Xfce по ум https://www.opennet.me/openforum/vsluhforumID3/112773.html#46 Mon, 20 Nov 2017 23:29:48 GMT &gt; Позже ещё причешу немного, там можно два прохода по массиву убрать почти за даром.<br><br>Мне вычисление разницы между директориями удалось до вот такого соптимизировать, но часть флагов еще ранее при readdir расставлена:<br><br>https://github.com/wulf7/libinotify-kqueue/blob/master/dep-list.c#L352<br> https://www.opennet.me/openforum/vsluhforumID3/112773.html#45 Mon, 20 Nov 2017 22:46:11 GMT Закинул за багтрекер годную рабочую версию патча.<br>И обошлось без тысяч строк ненужного кода, как в том что сейчас в глибе.<br><br>Позже ещё причешу немного, там можно два прохода по массиву убрать почти за даром.<br> https://www.opennet.me/openforum/vsluhforumID3/112773.html#44 Mon, 20 Nov 2017 21:18:26 GMT &gt; Ложная тревога.<br>&gt; Потерял EV_CLEAR и получил постоянный поллинг и 100% утилизации одного ядра.<br><br>glib-овский монитор, и оригинальный от libinotify вообще EV_ONESHOT вместо EV_CLEAR использовали. Хорошая база для глюкодрома.<br> https://www.opennet.me/openforum/vsluhforumID3/112773.html#43 Mon, 20 Nov 2017 21:14:57 GMT &gt; По прежнему смущает что постоянно будет открыта куча файлов RO.<br><br>Открытый файл - это просто несколько структур аллоцированных в памяти. Лежат себе и лежат, никому кроме unmount-a не мешают. Главное лимит на них не достичь. Вот тогда уже .опа.<br><br>&gt; я так понимаю что glib ждёт не рекурсивного мониторинга<br><br>Я тоже это так понимаю.<br> https://www.opennet.me/openforum/vsluhforumID3/112773.html#42 Mon, 20 Nov 2017 00:42:33 GMT Ложная тревога.<br>Потерял EV_CLEAR и получил постоянный поллинг и 100% утилизации одного ядра.<br> https://www.opennet.me/openforum/vsluhforumID3/112773.html#41 Mon, 20 Nov 2017 00:40:51 GMT Ok, убедил.<br>Пожалуй и правда периодические пачки fstatat() хуже одного open() + kevent().<br>Сделаю опционально (define) чтобы мониторило все элементы в папке на локальных фс, а полинг с таймером выкину.<br><br>По прежнему смущает что постоянно будет открыта куча файлов RO.<br>И насчёт рекурсивности - я так понимаю что glib ждёт не рекурсивного мониторинга, а только конкретного файла/папки, когда ему нужна рекурсия он отдельно спрашивает каждый элемент.<br> https://www.opennet.me/openforum/vsluhforumID3/112773.html#40 Sun, 19 Nov 2017 21:55:07 GMT Как то не хорошо класть болт на всех у кого проц не коре последних 5 лет.<br>Как минимум есть ещё всякие хромбуки на арм, не говоря о том, что я сидел на коредуо до этого года.<br><br>Мне плевать на концепцию глиб, как и им на всех BSD~шников, включая маководов.<br>Создать внутренний список-очередь на одном таймере можно, но по факту это получится реимплементация того что в ядре.<br>У меня подобная хотелка уже лет 5 есть (для других моих проектов), но всё никак не реализую в виду того что возни много а профита чуть.<br> https://www.opennet.me/openforum/vsluhforumID3/112773.html#39 Sun, 19 Nov 2017 15:42:15 GMT Лично мне поллинг по таймеру на локальной фс представляется более накладным нежели открытие всех файлов. Файлы все-таки открываются только один раз, а не каждые 5 секунд. Разве только если kern.maxfiles не хватает.<br>На сетевых он вообще может оказаться вредным, если заблокирует воркера из-за подвисшего соединения.<br> https://www.opennet.me/openforum/vsluhforumID3/112773.html#38 Sun, 19 Nov 2017 14:39:55 GMT &gt; Идея мониторить каждый отдельный файл и папку мне кажется очень плохой<br>&gt; куча сисколов<br><br>Сам по себе этот параметр не имеет смысла. Если имеется ввиду большие накладные расходы на переход в ядро и обратно, то они несущественны на невинтажном десктопном железе. На моем ноуте 5-летней давности рекурсивный запуск inotifywatch на хомяке длится менее секунды, За это время успевают начать мониториться 50000 файлов в разнообразных поддиректориях.<br><br>&gt; куча дескрипторов<br><br>Это уже реальное ограничение, но тоже на современном десктопном железе проявляющееся достаточно редко. kern.maxfiles автотюнится примерно из расчета 32k filedes/1GB RAM, что дает возможность одновременно мониторить до 100000 файлов на 4GB RAM десктопе без дополнительного тюнинга.<br><br>&gt; Хочу отдельный таймер на каждый мониторящийся объект, юзерам желательно будет подкрутить kern.kq_calloutmax.<br><br>Обычно чтобы обойти такое ограничение делают очередь из планируемых событий и создают один таймер который обрабатывает эту очередь. Но я не знаю легко ли э