Artem Chuprina <r...@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'е можно жить.. Только вот на чем тот бакап хранить, чтоб не понадобилось делать бакап-бакапа-бакапа.
