Search
Write a publication
Pull to refresh
63
0
Andrei Vagin @avagin

Системный программист

Send message
Надо понимать, что большая часть людей разрабатывает ядро за деньги. На мой взгляд, основная проблема — это практически полное отсутствие тестов. Они потихоньку появляются, но пока это все в очень начальном состоянии. Мы гоняем CRIU тесты на linux-next, и даже они ловят багов в ядре столько, что мы не успеваем их разгребать. Обычно, ждем пару дней и вот если баг не рассасывается, начинаем смотреть.
И это поправил. Спасибо. Кажется, надо быть более внимательным:).
Поправил. Спасибо. Рад, что кто-то дочитал статью до конца;)
AntonVirtual, так как есть у вас патчи к ядрам, или вы только потенциально можете там фиксить баги, но пока ни разу не пробовали?
Да, и вы опять противоречите себе. То у вас нет своего ядра, то вы там что-то фиксите и накатываете? Где можно посмотреть ваши фиксы к вашему же ядру? Вы же знаете, что их надо выкладывать в публичный доступ?
Т е вы без опыта разработки ядра, полезете и все там пофиксити? Извините, не верю, что из этого что-то хорошее получится. Одна из идей работы с апстримом — это подтверждение свой компетенции. Если вы ничего не делаете с ядром, а потом вдруг решаете там что-то пофиксить, скорей всего ничего хорошего не получится. И вот такие вот фиксы, я бы называл грязным вмешательством без кавычек.
Приходит к вам пользователь, говорит: «У меня ядро падает на вашей платформе». А вы ему: «Это бага в апстриме, мы не работаем за идею!».
То что вы называете «грязным вмешательством» имеет хороший выхлоп в upstream. Кроме того, что мы добавляем новую функциональность, мы регулярно находим баги в апстримном ядре и фиксим их. К слову о том, кто тут может обеспечить поддержку своих продуктов, я не поленился и посмотрел сколько раз ваша компания упоминается в ядре. Ровно два раза! Это нам говорит, что ядро не входит в вашу поддержку. Может проверим и остальные компоненты?

Вы не совсем понимаете, как работает opensource, иначе вас бы не удивляло, что наш kvm для некоторых типов нагрузок работает быстрее. Приведу простой пример. Нами была реализована хостовая часть драйверов hyper-v, что позволило виндовым гостям взлетать с нативными драверами и использовать все прелести паравиртуализации. Вся эта функциональность тут же ушла в апстрим, но в rhel она появится в следующем мажорном релизе, а у нас уже все работает, и до следующего релиза будут новые фишки.
Изначально, я свой интерфейс делал через netlink, но неожиданно для себя обнаружил, что этот мощный интерфейс считается для нужд сетевой подсистемы и некоторые попытки использования его в других подсистемах плохо себя показали. Это я к тому, что если надо мой новый интерфейс не имеет жестких завязок на /proc.

Сама идея файловой системы /proc не является ошибочной. На пример, в /proc есть «magic symlink» (/proc/pid/root, /proc/pid/fd/X, /proc/pid/cwd, etc), которые вряд ли получится заменить на что-то координатно другое.
Нет, не приведет. На самом деле все файлы в /proc это запрос на какие-то данные, т е сама по себе эта проблема решена давно.
Через livepatch можно делать относительно простые изменения, которые не затрагивают изменения структур данных. Да и ядра для убунты нет.
Для вашего примера, LXC более чем достаточен. OpenVZ используется, когда действительно нужна изоляция контейнеров друг от друга, когда контейнеры отдаются в третьи руки, а в этом случае базовый дистрибутив играет уже второстепенную роль.
Понятие «работает» у всех разное. В случае с OpenVZ доступ к контейнеру можно отдать кому угодно. В случае с LXC этого сделать нельзя, потому что пользователь в контейнере довольно легко может положить всю ноду. Если вам нужен chroot для запуска отдельного окружения, то LXC легко справится с этой задачей. Если вы хотите отдавать доступ к контейнеру в третьи руки, то LXC вам не подходит.

В 2009 году в LXC работы с памятью просто не было, там и сегодня не все так хорошо. В OpenVZ в то время использовались UBC, которые действительно вызывали много вопросов у пользователей. Сегодня схема работы с памятью совсем другая и она сильно приближена к обычно системе. У контейнера есть два лимита на память и на своп.
А вы когда последний раз VZ использовали? Судя по комментарию в то время, когда там были UBC или LSM.
По ходу 41 воздержавшийся тоже не нашли этого варианта;). Думаю тебе подошел бы еще ответ: «Так я же еще 8 лет назад это делал».
Если это будет чистое qemu (без kvm), то должно задампиться. С kvm все сложнее, там часть стейта в ядре и его нужно как-то сохранять. Мы этим не занимались, потому что у qemu есть свой механизм миграции и он работает более оптимально, чем это сделаем CRIU.
Баги в CRIU, которые нашли тут, пофиксим. Остальное пока под вопросом.
Можно сказать docker run, но это будет не одно и то же. Во-первых, ядро будет старое. Во-вторых, в Dockere трудно стартануть всю систему целиком. В-третьих, Travis был просто взят для примера. Применений у этого подхода масса. У меня вот сейчас крутится джоб, который тестирует Linux-next ядра.
Я сначала отладил перезагрузку через kexec и только потом добавил обновление системы. Просто перезагрузка занимает пару минут, с обновлением минут 15-20.

На самом деле не так там все и медленно. Вот, на пример, джоб с компиляцией ядра и прогоном всех наших тестов бежит за пол часа https://travis-ci.org/avagin/criu/builds/186831426
Смотри, оказывается тесты в трависе гоняются и уже несколько месяцев https://travis-ci.org/xemul/criu/jobs/130000751.

Еще мы используем patchwork https://zdtm.openvz.org/project/criu/series/?ordering=-last_updated
И статический анализатор кода https://scan.coverity.com/projects/avagin-criu
Это зависит от диска, точнее от его кеша.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity