Re: научите systemd!

["Andrey Jr. Melnikov" <temnota.am@gmail.com>]

Artem Chuprina <ran@lasgalen.net> wrote:
> Andrey Jr. Melnikov -> debian-russian@lists.debian.org  @ Mon, 26 Feb 2018 22:45:28 +0300:

>  >>  >> Чтоб два раза не вставать: я понимаю, почему юзерский юнит не может
>  >>  >> прописать зависимость от системного. (В документации, кстати, я этого не
>  >>  > А я вот не понимаю. Все эти приседания вокруг Before|After|Requires|Want
>  >>  > напоминают те-же циферки в sysvinit. Только в профиль. Теперь с D-BUS'ом.

>  >> Правов у него нет. Информация о зависимостях и, главное, степени успеха
>  >> запуска оных, есть у systemd унутре. В отдельной cgroup. Юзерский
>  >> systemctl (или отдельный экземпляр systemd?) туда не пускают.
>  > Это ЭПИЧНЫЙ ВИН Лёни. Имея унутре dbus - не иметь доступа на спросить - это
>  > ШЕСТЬ. Это даже не пять.

> Ну, что я тебе могу сказать? Такой вот у нас нынче init. От него еще и
> драйвера принтеров теперь зависят...
Не от него а от udev'а вмноличенного в этот комбайн. Ну да ладно, это уже
тонкости реализации.

>  >>  >> нашел, но гуглится.) Но я уже перестаю понимать, почему автор такой
>  >>  >> архитектуры до сих пор не поскользнулся на арбузной корке...
>  >>  > А зачем ему убиваться-то? Вся аудитория этого комбайна - качественно
>  >>  > окучена до предела "а вы так не делайте", скоро будет переустанавливать
>  >>  > систему если DM не запускается. Или в платный саппорт.

>  >> Угу. Я уже тут прошелся по граблям с тем же zfs. Конфиги для старта в
>  >> дистрибутиве у него есть только для systemd, поэтому на сервере, где у
>  >> меня zfs, я его оставил. Ну и... zfs mount -a при старте системы
>  > А расскажите мне, что вы так бегаете с этим zfs? Решение же не для нищих,
>  > так еще и мертвое. Что вы в нем такого супер-пупер находите?
>  > Память жрет как свинья помои? Причем память подай с ECC и вагон.
>  > Компрессия? Восстановление данных после сбоя?
>  > Чем этот кусок почившей SunOS так хорош-то, что его добровольно тянут во все места?

> Вообще в SunOS было немало хороших вещей. Иногда стоит что-нибудь и
> подтянуть.
Зачем? Если она была такая все из себя перспективная и бац "тузик сдох и
больше не воняет". А то что осталось от трупика - закопирайчено так, что
даже не разлагается.
Вон один уже повосхищался идеями из SMF. Скажите спасибо, что вы еще XML не
редактируете в java тулзе.

> Меня привлекает в нем идея, что можно делать тома с разными свойствами,
> распределяемые по пространству диска динамически. Без танцев с ресайзом,
> где каждую вторую файловую систему нельзя уменьшить без отмонтирования,
> а каждую четвертую - и увеличить...
А зачем это нужно? Нет, реально - зачем? Мне видиться только один вариант
использования - петабайтные хранилища. Но там увы своё железо и свои fs.

> Еще в нем обещали намного более аккуратно сделанный рейд, нежели в
> обычной архитектуре, с намного более нежным по отношению к дискам
> ребилдом. Но на практике не проверял :)

Эмм, сомнительное достижение. Любой контроллер имеет ручку rebuild rate,
которую можно покрутить.

> Память он, кстати, жрет весьма умеренно, если дедупликацию не
> включать.

>               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 и компрессии нет, да. 

> Компрессия, да, приятное дополнение, но насколько я понимаю, ее и еще
> кто-то умел. Вдумчивая проверка целостности - но да, ECC оно хочет. Но
> они меня, в общем, убедили, что если хочешь целостности, надо хотеть и
> ECC. С любой FS. Просто без ECC ZFS в случае сбоев памяти начнет
> ругаться раньше, когда меньше данных поломали. А остальные будут делать
> вид, что все хорошо.
А как ваш волшебный ZFS догадается, что произошла битовая ошибка в момент
чтения памяти контроллером DMA при перекачке странцы в контроллер SATA?
Только считав её (страницу) назад с диска и сравнив checksumm?

А если взять более реальный вариант обсчета каких нибудь матриц в GPU - то
туда тоже заносить память с ECC? Вот ведь геймеры будут рады, что их шейдеры
теперь защищены ценой потери производительности в 3-5% и ценником на видяху
в 15-20%.

ECC - это увы очень дорогостоящий обвес, т.к. затрагивает не только саму
планку памяти - а все шины до перефирии.

> Как у нас сейчас на разных FS обстоят дела с восстановлением после сбоя,
> я не копал. Журналируемая каждая первая, скоро, наверное, уже
> журналируемый FAT сделают. А вот насколько хорошо оно восстанавливается,
> если что... В документации на ZFS было довольно подробно расписано,
> когда у нее что куда пишется, и где делается синхронизация на диски.
Т.е. становимся в позу "я у мамки хакир" и начинаем приседания вокруг
hex-редакторов и дампов дисков?