Artem Chuprina <r...@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-редакторов и дампов дисков?