Andrey Jr. Melnikov -> debian-russian@lists.debian.org @ Mon, 5 Mar 2018 15:14:32 +0300:
>> >> >> >> Чтоб два раза не вставать: я понимаю, почему юзерский юнит не >> может >> >> >> >> прописать зависимость от системного. (В документации, кстати, я >> этого не >> >> >> > А я вот не понимаю. Все эти приседания вокруг >> Before|After|Requires|Want >> >> >> > напоминают те-же циферки в sysvinit. Только в профиль. Теперь с >> D-BUS'ом. >> >> >> Правов у него нет. Информация о зависимостях и, главное, степени >> успеха >> >> >> запуска оных, есть у systemd унутре. В отдельной cgroup. Юзерский >> >> >> systemctl (или отдельный экземпляр systemd?) туда не пускают. >> >> > Это ЭПИЧНЫЙ ВИН Лёни. Имея унутре dbus - не иметь доступа на >> спросить - это >> >> > ШЕСТЬ. Это даже не пять. >> >> Ну, что я тебе могу сказать? Такой вот у нас нынче init. От него еще и >> >> драйвера принтеров теперь зависят... >> > Не от него а от udev'а вмноличенного в этот комбайн. Ну да ладно, это уже >> > тонкости реализации. >> Не, они там от policykit чего-то хотели. udev, в общем, > Интересно, а зачем это нужно в случае принтера. С флешками как-то еще > понятно, но вот с принтером... Подозреваю, нотификации юзеру о втыкании принтера в USB. >> отсоединен. Впрочем, кажется, то, чего они хотели от policykit, тоже >> отсоединено, только надо более вдумчиво попинать aptitude. > Увы - udev вмоноличен, а то что они идет отдельным пакетиком - так вышло. > Как выкинут sysvinit - так сразу станет всё в одном. Выкинут - поставлю FreeBSD. >> >> Меня привлекает в нем идея, что можно делать тома с разными свойствами, >> >> распределяемые по пространству диска динамически. Без танцев с ресайзом, >> >> где каждую вторую файловую систему нельзя уменьшить без отмонтирования, >> >> а каждую четвертую - и увеличить... >> > А зачем это нужно? Нет, реально - зачем? Мне видиться только один вариант >> > использования - петабайтные хранилища. Но там увы своё железо и свои fs. >> Ровно наоборот. Когда диска некоторый дефицит. > Когда диска дефицит - надо идти за новым. Или посылать счет в бухгалтерию. > Собирать оделяо из лоскутков - ну, в виде развлечения и народных промыслов > только интересно. Идти за новым не всегда своевременно. Он все-таки не три копейки стоит, особенно если тихий. >> >> Память он, кстати, жрет весьма умеренно, если дедупликацию не >> >> включать. >> >> 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%. >> А геймерам целостность низачем. > А других видях не делают. Точнее - нонче делают, но за другие деньги. А на > геймерских считать увы "ай-ай-ай, гарантии лишим". А зачем мне обсчитывать матрицы в GPU? В чексуммах целочисленная арифметика.
