Re: научите systemd!
Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Sat, 3 Mar 2018 21:50:51 +0300:
>> >> >> Чтоб два раза не вставать: я понимаю, почему юзерский юнит не может
>> >> >> прописать зависимость от системного. (В документации, кстати, я этого не
>> >> > А я вот не понимаю. Все эти приседания вокруг Before|After|Requires|Want
>> >> > напоминают те-же циферки в sysvinit. Только в профиль. Теперь с D-BUS'ом.
>> >> Правов у него нет. Информация о зависимостях и, главное, степени успеха
>> >> запуска оных, есть у systemd унутре. В отдельной cgroup. Юзерский
>> >> systemctl (или отдельный экземпляр systemd?) туда не пускают.
>> > Это ЭПИЧНЫЙ ВИН Лёни. Имея унутре dbus - не иметь доступа на спросить - это
>> > ШЕСТЬ. Это даже не пять.
>> Ну, что я тебе могу сказать? Такой вот у нас нынче init. От него еще и
>> драйвера принтеров теперь зависят...
> Не от него а от udev'а вмноличенного в этот комбайн. Ну да ладно, это уже
> тонкости реализации.
Не, они там от policykit чего-то хотели. udev, в общем,
отсоединен. Впрочем, кажется, то, чего они хотели от policykit, тоже
отсоединено, только надо более вдумчиво попинать aptitude.
>> > А расскажите мне, что вы так бегаете с этим zfs? Решение же не для нищих,
>> > так еще и мертвое. Что вы в нем такого супер-пупер находите?
>> > Память жрет как свинья помои? Причем память подай с ECC и вагон.
>> > Компрессия? Восстановление данных после сбоя?
>> > Чем этот кусок почившей SunOS так хорош-то, что его добровольно тянут во все места?
>> Вообще в SunOS было немало хороших вещей. Иногда стоит что-нибудь и
>> подтянуть.
> Зачем? Если она была такая все из себя перспективная и бац "тузик сдох и
> больше не воняет". А то что осталось от трупика - закопирайчено так, что
> даже не разлагается.
Маркетинговая политика у нее была никуда не годная. Вот и сдохло. Мы
тоже скоро сдохнем. А отдельные куски там были проработаны неплохо, нам
бы так.
>> Меня привлекает в нем идея, что можно делать тома с разными свойствами,
>> распределяемые по пространству диска динамически. Без танцев с ресайзом,
>> где каждую вторую файловую систему нельзя уменьшить без отмонтирования,
>> а каждую четвертую - и увеличить...
> А зачем это нужно? Нет, реально - зачем? Мне видиться только один вариант
> использования - петабайтные хранилища. Но там увы своё железо и свои 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%.
А геймерам целостность низачем.
>> Как у нас сейчас на разных FS обстоят дела с восстановлением после сбоя,
>> я не копал. Журналируемая каждая первая, скоро, наверное, уже
>> журналируемый FAT сделают. А вот насколько хорошо оно восстанавливается,
>> если что... В документации на ZFS было довольно подробно расписано,
>> когда у нее что куда пишется, и где делается синхронизация на диски.
> Т.е. становимся в позу "я у мамки хакир" и начинаем приседания вокруг
> hex-редакторов и дампов дисков?
Не, я имею в виду не восстановление после фатальных сбоев самой ZFS, а
восстановление после сбоев питания и дисков.
Восстановление после фатального сбоя FS, насколько я понимаю, нынче
разумное только одно: mkfs и развернуть бэкап.
Reply to: