Вышел cgroups v2

Документ обьясняющий unified hierarchy: https://git.kernel.org/cgit/linux/kernel/git/tj/cgroup.git/tree/Documentation...

Документация по cgroups v2: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Document...

Презентация от Теджуна на NYLUG этим летом: https://www.youtube.com/watch?v=PzpG40WiEfM

краткий вопрос: - совместимость вниз - (ожидается | уже есть) ?

cgroups v2 уже обкатан в продакшене в Фейсбуке

Вот это неплохой способ коммитить что-то в ядро.

Механизм ядра cgroups широко используется такими важными и популярными инструментами, как Docker, Hadoop, Kubernetes, LXC, Mesos и CoreOS.

systemd допишите.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Document...

Говорят что «mixing v2 hierarchy with the legacy v1 multiple hierarchies in a fully backward compatible way».

Щупать надо самим, короче, но совместимость закладывалась - уже радует.

Подтверждать-то будет, или у тебя есть возражения какие-то?

Вот что значит приходить в темы из трекера - я, блин, даже не заметил что это новость :-/

Звучит интересно. Спасибо за новость.

Вот это неплохой способ коммитить что-то в ядро.

единственный для нас. все тестируется в приватных бранчах перед тем как апстримить.

я хейтер ^_^

теперь следует ожидать нового прогрессивного инновационного systemd v2?

больше интересно коммиты к btrfs которую они пилят увидеть, особенно было бы весело, чтобы subvol стали блочным устройством.

subvol стали блочным устройством

Файловая система, которая реализует тома, которые отдаются как блочные устройства? SOMETHING IS SERIOUSLY BROKEN OUT THERE.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/fs/btrfs любуйся, ничего секретного. там почти все, с Крисом Мейсоном во главе — инженеры Фейсбука.

system2d

А что это означает для пользователя?

это вы авторам ZFS скажите...

ZFS? На самом деле, сейчас понятие ФС вышло за уровень собственно файловой системы.

Ура! По мне так первичная фишка cgroups не контроллеры, а возможность иерархически маркировать процессы, чем и пользуется systemd.

Теперь же появилась возможность прикручивать менеджеры на поддеревья. Т.е. Поттеринг, пугающий unified hieracy, таки пукнул в лужу.

Это отличнейший повод для systemd-xeйтеров погнать systemd из PID 1.

А для systemd-филов — сделать systemd рекурсивным.

ZFS?

Да, я в курсе.

На самом деле, сейчас понятие ФС вышло за уровень собственно файловой системы.

У кого вышло?

systemd v2

systemg v1

Очень радует.

Проклятый Поттеринг дотянулся.

Тестировать в приватных бранчах это ок, я имею ввиду именно обкатку в продакшене.

я тоже =)

я не понял, можешь подробнее обьяснить плиз? если что, я знаю что делает этот чейндж и пользуюсь им в проде. но я не пользуюсь системд нигде. как это поможет «заменить системд»? что такого уникального дает системд в pid 1 по отношению к cgroups?

На самом деле, сейчас понятие ФС вышло за уровень собственно файловой системы

так и есть

Насколько я понимаю, изначально systemd имел свою иерархию процессов (маркировка процессов согласно их запуску сервисами), а logind - свою (маркировка процессов согласно их запуску пользовательскими сессиями). Потом в ведре решили отказаться от множественных иерархий и контроллеров, и Леня вынес все управление cgroups в systemd, а logind прибил к нему гвоздями (при том, что некоторые non-systemd дистры успели принять logind без systemd). Сейчас вроде как можно сделать обратно - оба будут управлять одной иерархией, systemd будет разбивать ее по сервисам, а logind внутри сервисов, порождающих пользовательские сеансы, будет создавать сеансовые поддеревья. Ну или прямо в корне, если будет использоваться без systemd.

я не понял, можешь подробнее обьяснить плиз?

В cgroups можно сделать группу не прицепленную к контроллеру. Смысл? Можно иерархически маркировать процессы, *как бы они и в каком порядке бы не форкались*. Исключительно ради этого и затевался systemd.

Systemd не требуется вести БД разной степени ущербности, для соответствия метка сервиса -> PID. Ему достаточно просканить свою группу и получить данные «из первых рук».

Уже тогда было понятно, что cgroups в таком виде не очень удобны. Практически сразу встал вопрос о unified hierarchy. Проблема в том, что в cgroups1 в рамках одной иерархии, уведомления мог получать только один процесс через достаточно кривой механизм. Т.е. при если бы UH была бы применена в таком виде как сейчас, в системе мог быть бы только один Д'Артаньян, все остальные — ...

Другое дело, что за столько лет, несмотря на эпические потоки говна излитого в адрес Поттеринга, соперников на должности главного Д'Артаньяна у systemd так и не появилось.

Возможность введения UH была одним аргументов Поттеринга по поводу дизайна systemd и необходимости объединения функционала PID 1 и менеджера cgroups. Да и внедрения systemd вообще.

Теперь, судя по докам, это неактуально. Д'Артаньянов может быть не один, и каждый Д'Артаньян будет тихо-мирно получать своё подмножество уведомлений по своему поддереву меток/контроллеров.

понятно, спасибо.

только одна унифицированная иерархия

Отлично. Реальный юз-кейс для множественных иерархий даже придумать трудно, никогда не понимал зачем их сделали.

стандартизированный подход это хорошо, но стал ли он работать лучше?

фоточке суши быстрее зааплоадятся на стену

systemd допишите.

А там разве не своя реализация?

А оно вроде реализацию ядра пользует. По крайней мере, при сборке в генте включать CGROUPS надо.

нет конечно. как ты представляешь себе «свою реализацию» ядренного механизма.

А насколько полно реализованы ограничения дискового пространства в контейнерах сейчас? Ну в том плане что с этим вроде были какие-то проблемы...

Говорим «фейсбук», подразумеваем «закладки спецслужб».

с нетерпением жду твоего анализа закладок спецслужб в cgroupsv2, кулхацкир мамкин. шапочка не жмет?

А насколько полно реализованы ограничения дискового пространства в контейнерах сейчас? Ну в том плане что с этим вроде были какие-то проблемы...

именно обьема дискового пространства? никак, и никогда небыли. cgroups позволяет управлять гораздо более сложными и ценными параметрати IO: очередями, иопс, пропускной способностью. квотами занимается механизм квот и разрешений фс. но это все морально устарело, если есть такая необходимость, проще всего создать отдельную фс под этот контейнер, механизмов для этого масса в зависимости от типа контейнера. для «голых» cgroups вероятно надо замаппить эту фс как единственную rw фс в namespace этой группы.

Теперь, судя по докам, это неактуально. Д'Артаньянов может быть не один, и каждый Д'Артаньян будет тихо-мирно получать своё подмножество уведомлений по своему поддереву меток/контроллеров.

По своему поддереву меток (т. е. поддереву в иерархии). Насколько я понимаю, два процесса не могут рулить разными контроллерами одного и того же поддерева.

Ну а «рекурсивный systemd» таки уже есть.

Насколько я понимаю, два процесса не могут рулить разными контроллерами одного и того же поддерева.

Могут. Главное, чтобы управляющие процессы не гадили друг другу в чай...

Но тут моё cgroups-фу заканчивается. Нужно смотреть исходники, а лучше ставить тестовое ядро. Последнее, слегка проблематично на современных дистрах: спасибо Поттерингу.

Нужно смотреть исходники, а лучше ставить тестовое ядро. Последнее, слегка проблематично на современных дистрах: спасибо Поттерингу.

А в чем сложность? Ведь cgroupsV1 никуда не делась и поделие поттеринга будет также работать на новом ядре. Монтируешь новый cgroup в другую ветку и тестируешь что нужно.

Последнее, слегка проблематично на современных дистрах: спасибо Поттерингу.

systemd.unified_cgroup_hierarchy=1 >> /proc/cmdline

systemd капец или Поцеринг предложит groupsd?

а лучше ставить тестовое ядро. Последнее, слегка проблематично на современных дистрах: спасибо Поттерингу.

А гентушники-то и не знали. В чём проблема в любом дистрибутиве собрать своё ядро из транка?

systemd уже полгода как поддерживает новый API.

уже обкатан в продакшене в Фейсбуке

Вот это я понимаю тестирование.

/proc/cmdline read-only :D

Кстати там все очень толково и круто наконец-то сделали.