Re: научите systemd!
Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Mon, 5 Mar 2018 15:14:32 +0300:
>> >> >> >> Чтоб два раза не вставать: я понимаю, почему юзерский юнит не может
>> >> >> >> прописать зависимость от системного. (В документации, кстати, я этого не
>> >> >> > А я вот не понимаю. Все эти приседания вокруг Before|After|Requires|Want
>> >> >> > напоминают те-же циферки в sysvinit. Только в профиль. Теперь с D-BUS'ом.
>> >> >> Правов у него нет. Информация о зависимостях и, главное, степени успеха
>> >> >> запуска оных, есть у systemd унутре. В отдельной cgroup. Юзерский
>> >> >> systemctl (или отдельный экземпляр systemd?) туда не пускают.
>> >> > Это ЭПИЧНЫЙ ВИН Лёни. Имея унутре dbus - не иметь доступа на спросить - это
>> >> > ШЕСТЬ. Это даже не пять.
>> >> Ну, что я тебе могу сказать? Такой вот у нас нынче init. От него еще и
>> >> драйвера принтеров теперь зависят...
>> > Не от него а от udev'а вмноличенного в этот комбайн. Ну да ладно, это уже
>> > тонкости реализации.
>> Не, они там от policykit чего-то хотели. udev, в общем,
> Интересно, а зачем это нужно в случае принтера. С флешками как-то еще
> понятно, но вот с принтером...
Подозреваю, нотификации юзеру о втыкании принтера в USB.
>> отсоединен. Впрочем, кажется, то, чего они хотели от policykit, тоже
>> отсоединено, только надо более вдумчиво попинать aptitude.
> Увы - udev вмоноличен, а то что они идет отдельным пакетиком - так вышло.
> Как выкинут sysvinit - так сразу станет всё в одном.
Выкинут - поставлю FreeBSD.
>> >> Меня привлекает в нем идея, что можно делать тома с разными свойствами,
>> >> распределяемые по пространству диска динамически. Без танцев с ресайзом,
>> >> где каждую вторую файловую систему нельзя уменьшить без отмонтирования,
>> >> а каждую четвертую - и увеличить...
>> > А зачем это нужно? Нет, реально - зачем? Мне видиться только один вариант
>> > использования - петабайтные хранилища. Но там увы своё железо и свои fs.
>> Ровно наоборот. Когда диска некоторый дефицит.
> Когда диска дефицит - надо идти за новым. Или посылать счет в бухгалтерию.
> Собирать оделяо из лоскутков - ну, в виде развлечения и народных промыслов
> только интересно.
Идти за новым не всегда своевременно. Он все-таки не три копейки стоит,
особенно если тихий.
>> >> Память он, кстати, жрет весьма умеренно, если дедупликацию не
>> >> включать.
>> >> total used free shared buff/cache available
>> >> Mem: 3935296 2414300 1420856 29512 100140 1338100
>> >> Swap: 4194300 46848 4147452
>> >> Диск 4 терабайта, и помимо файлосерверения машина занята только
>> >> роутингом. Еще оно при записи подтормаживает, но там двухъядерный
>> >> гигагерцовый целерон, и включена компрессия.
>> > Файло помойка без роутинга, дисков на 8 терабайт:
>> > total used free shared buff/cache available
>> > Mem: 8172772 103200 288628 29116 7780944 7734592
>> > Swap: 1951740 0 1951740
>> > ZFS и компрессии нет, да.
>> Если ты хотел помериться, то ты победил. Но я мериться не предлагал. Я
>> всего лишь показал, что у меня оно в небольшую, в общем, память
>> нормально влезает.
> Не, меряться я не хотел. Хотел показать, что a) по выводу free нефига не
> понятно, сколько жреть этот ZFS, b) у машины без zfs тупо больше места под
> дисковые кэши.
Ну, меня в данном случае интересует интегральная характеристика "хватает
памяти или маловато". Хватает. Дисковые кэши мне там не особо нужны.
>> >> Компрессия, да, приятное дополнение, но насколько я понимаю, ее и еще
>> >> кто-то умел. Вдумчивая проверка целостности - но да, ECC оно хочет. Но
>> >> они меня, в общем, убедили, что если хочешь целостности, надо хотеть и
>> >> ECC. С любой FS. Просто без ECC ZFS в случае сбоев памяти начнет
>> >> ругаться раньше, когда меньше данных поломали. А остальные будут делать
>> >> вид, что все хорошо.
>> > А как ваш волшебный ZFS догадается, что произошла битовая ошибка в момент
>> > чтения памяти контроллером DMA при перекачке странцы в контроллер SATA?
>> > Только считав её (страницу) назад с диска и сравнив checksumm?
>> Да. У него для этого специальная ручка есть, рекомендуемая для запуска
>> по крону.
> Дык такая ручка и у mdadm'a есть и у железных контроллеров. Всякие там
> Patrol Read/Background consistency check, и от живости cron'a не зависят.
Если рейд, то да, пожалуй, можно.
>> > А если взять более реальный вариант обсчета каких нибудь матриц в GPU - то
>> > туда тоже заносить память с ECC? Вот ведь геймеры будут рады, что их шейдеры
>> > теперь защищены ценой потери производительности в 3-5% и ценником на видяху
>> > в 15-20%.
>> А геймерам целостность низачем.
> А других видях не делают. Точнее - нонче делают, но за другие деньги. А на
> геймерских считать увы "ай-ай-ай, гарантии лишим".
А зачем мне обсчитывать матрицы в GPU? В чексуммах целочисленная арифметика.
Reply to: