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 и развернуть бэкап.
