Re: научите systemd!
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. От него еще и
драйвера принтеров теперь зависят...
>> >> нашел, но гуглится.) Но я уже перестаю понимать, почему автор такой
>> >> архитектуры до сих пор не поскользнулся на арбузной корке...
>> > А зачем ему убиваться-то? Вся аудитория этого комбайна - качественно
>> > окучена до предела "а вы так не делайте", скоро будет переустанавливать
>> > систему если DM не запускается. Или в платный саппорт.
>> Угу. Я уже тут прошелся по граблям с тем же zfs. Конфиги для старта в
>> дистрибутиве у него есть только для systemd, поэтому на сервере, где у
>> меня zfs, я его оставил. Ну и... zfs mount -a при старте системы
> А расскажите мне, что вы так бегаете с этим zfs? Решение же не для нищих,
> так еще и мертвое. Что вы в нем такого супер-пупер находите?
> Память жрет как свинья помои? Причем память подай с ECC и вагон.
> Компрессия? Восстановление данных после сбоя?
> Чем этот кусок почившей SunOS так хорош-то, что его добровольно тянут во все места?
Вообще в SunOS было немало хороших вещей. Иногда стоит что-нибудь и
подтянуть.
Меня привлекает в нем идея, что можно делать тома с разными свойствами,
распределяемые по пространству диска динамически. Без танцев с ресайзом,
где каждую вторую файловую систему нельзя уменьшить без отмонтирования,
а каждую четвертую - и увеличить...
Еще в нем обещали намного более аккуратно сделанный рейд, нежели в
обычной архитектуре, с намного более нежным по отношению к дискам
ребилдом. Но на практике не проверял :)
Память он, кстати, жрет весьма умеренно, если дедупликацию не
включать.
total used free shared buff/cache available
Mem: 3935296 2414300 1420856 29512 100140 1338100
Swap: 4194300 46848 4147452
Диск 4 терабайта, и помимо файлосерверения машина занята только
роутингом. Еще оно при записи подтормаживает, но там двухъядерный
гигагерцовый целерон, и включена компрессия.
Компрессия, да, приятное дополнение, но насколько я понимаю, ее и еще
кто-то умел. Вдумчивая проверка целостности - но да, ECC оно хочет. Но
они меня, в общем, убедили, что если хочешь целостности, надо хотеть и
ECC. С любой FS. Просто без ECC ZFS в случае сбоев памяти начнет
ругаться раньше, когда меньше данных поломали. А остальные будут делать
вид, что все хорошо.
Как у нас сейчас на разных FS обстоят дела с восстановлением после сбоя,
я не копал. Журналируемая каждая первая, скоро, наверное, уже
журналируемый FAT сделают. А вот насколько хорошо оно восстанавливается,
если что... В документации на ZFS было довольно подробно расписано,
когда у нее что куда пишется, и где делается синхронизация на диски.
Reply to: