Re: научите systemd!
Artem Chuprina <ran@lasgalen.net> wrote:
> 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.
Увы - udev вмоноличен, а то что они идет отдельным пакетиком - так вышло.
Как выкинут sysvinit - так сразу станет всё в одном.
> >> > А расскажите мне, что вы так бегаете с этим zfs? Решение же не для нищих,
> >> > так еще и мертвое. Что вы в нем такого супер-пупер находите?
> >> > Память жрет как свинья помои? Причем память подай с ECC и вагон.
> >> > Компрессия? Восстановление данных после сбоя?
> >> > Чем этот кусок почившей SunOS так хорош-то, что его добровольно тянут во все места?
> >> Вообще в SunOS было немало хороших вещей. Иногда стоит что-нибудь и
> >> подтянуть.
> > Зачем? Если она была такая все из себя перспективная и бац "тузик сдох и
> > больше не воняет". А то что осталось от трупика - закопирайчено так, что
> > даже не разлагается.
> Маркетинговая политика у нее была никуда не годная. Вот и сдохло. Мы
> тоже скоро сдохнем. А отдельные куски там были проработаны неплохо, нам
> бы так.
Не-не-не.. Идеи там конечно хорошие, но реализации и вобще вся
инфраструктура - говно. Да еще и с затычками по времени, чтоб преставало
работать после определенной даты. Померла - так померла.
> >> Меня привлекает в нем идея, что можно делать тома с разными свойствами,
> >> распределяемые по пространству диска динамически. Без танцев с ресайзом,
> >> где каждую вторую файловую систему нельзя уменьшить без отмонтирования,
> >> а каждую четвертую - и увеличить...
> > А зачем это нужно? Нет, реально - зачем? Мне видиться только один вариант
> > использования - петабайтные хранилища. Но там увы своё железо и свои fs.
> Ровно наоборот. Когда диска некоторый дефицит.
Когда диска дефицит - надо идти за новым. Или посылать счет в бухгалтерию.
Собирать оделяо из лоскутков - ну, в виде развлечения и народных промыслов
только интересно.
> >> Еще в нем обещали намного более аккуратно сделанный рейд, нежели в
> >> обычной архитектуре, с намного более нежным по отношению к дискам
> >> ребилдом. Но на практике не проверял :)
> > Эмм, сомнительное достижение. Любой контроллер имеет ручку rebuild rate,
> > которую можно покрутить.
> Говорю же, не проверял. Но в документации ссылаются на исследования из
> датацентров, где рассказывают, что вероятность слета второго диска во
> время ребилда оказывается несколько более высокой, чем хотелось бы. А
> эти обещают, что они нежнее.
Обещать - не значит жениться, блин. Диски в случае ребилда дохнут больше
частью из-за того, что они из одной партии/коробки/уроненой при перегрузке
палеты. Меняй диски планово, по достижению 2х-3х летнего срока эксплуатации
с задержкой в 2-3 недели между заменой - и всё будет нормально. Но нет, это
же raid, надо 5 лет жарить диски выской температурой, нагрузками и потом
удивлятся - ой, а чё это они все разом сдохли?
> >> Память он, кстати, жрет весьма умеренно, если дедупликацию не
> >> включать.
> >> 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%.
> А геймерам целостность низачем.
А других видях не делают. Точнее - нонче делают, но за другие деньги. А на
геймерских считать увы "ай-ай-ай, гарантии лишим".
> >> Как у нас сейчас на разных FS обстоят дела с восстановлением после сбоя,
> >> я не копал. Журналируемая каждая первая, скоро, наверное, уже
> >> журналируемый FAT сделают. А вот насколько хорошо оно восстанавливается,
> >> если что... В документации на ZFS было довольно подробно расписано,
> >> когда у нее что куда пишется, и где делается синхронизация на диски.
> > Т.е. становимся в позу "я у мамки хакир" и начинаем приседания вокруг
> > hex-редакторов и дампов дисков?
> Не, я имею в виду не восстановление после фатальных сбоев самой ZFS, а
> восстановление после сбоев питания и дисков.
> Восстановление после фатального сбоя FS, насколько я понимаю, нынче
> разумное только одно: mkfs и развернуть бэкап.
С таким подходом и на FAT'е можно жить.. Только вот на чем тот бакап
хранить, чтоб не понадобилось делать бакап-бакапа-бакапа.
Reply to: