Ещё может помочь распространение обновлений не всем пользователям сразу, а поэтапно. А ещё бывает практика у опытных админов устанавливать обновления не на весь прод сразу, а после его обкатки на тестовом сервере.
Мне вообще странно читать статьи про многомиллиардные убытки от повреждения IT инфраструктуры, хотя средства резервного копирования изобретены уже давно.
Это будет модуль для фильтрации блоков ввода/вывода (bio).
Нет, конечно этот модуль фильтрации не решает проблему со снапшотами. Его назначение в другом. Он позволяет заблокировать доступ к каким-то областям диска. Например запретить на запись сектора, содержащие таблицу разделов. Или запретить доступ к разделу, за исключением какого-то процесса или модуля ядра. Это может быть очень полезно для баз данных.
Просто при добавлении такого модуля в upstream появляются и функции для подключения и отключения фильтров, а значит подключаться смогут и out-of-tree модули, так-же как это было до ядра 5.8.
Добавление модуля для создания снапшотов может быть следующим шагом. Но тут проблема в том, что в ядре уже есть dm-snap, а майнтейнеры не любят дубликатов. Я пробовал работать с Майком, майнтейнером DM, который работает в Red Hat. Скажем так, у меня не особо что получилось. Я полагаю что для Майка больше важна стабильность работы существующего кода, а не расширение его функционала, что вполне понятно.
Поэтому, чтобы «не уйти в закат» прям сразу, мне видится задача: поднять актуальность проблемы в глазах майнтейнеров и всего сообщества пользователей Linux. Если будут положительные отзывы о патче со стороны разных людей (разных компаний), и они подтвердят необходимость такого фильтра в их работе — то шанс попасть в ядро резко возрастает. Нужно изметить статус проблемы от «патч какого-то выскочки» в «реально нужная фича».
Я готовлю RFC, чтобы обсудить это в upstream перед запуском самого патча. Есть ещё вариант написать статью в lwn. Но для начала решил сделать статью для Хабра.
Я, как-то, если честно, рассчитывал на какой-нибудь feedback по коду.
Вся статья ради этого предложения:
Кому интересно взглянуть, мой репозиторий тут. Ветка на базе ядра 5.12 здесь. Для 5.13 тоже есть ветка.
Так что дочитывать необязательно, можно сразу смотреть код. Найдёте баг — заводите issue, ну или сразу pull request.
В статье я старался в простой и доступной большинству форме обозначить проблему, которую я пытаюсь решить. Может кто-то тоже столкнулся с этой проблемой и ищет решение. Могли бы объединить усилия.
Шутки про сисадмина — чтобы читалось легче и создавало позитивный эмоциональный фон. Возможно, вы не поняли шутки про разные шляпы и шапочки? Это нормально.
Может вам в квн?)
— извините, даже не смотрю уже лет пятнадцать. Не смешно.
Долго думал как ответить. VBR для машин на ESX и Hyper-V (ещё Nutanix AHV) повезёт Linux со снапшотами и change-tracking. Там снапшоты и CBT реализуются гипервизором. Если физическая тачка (или иной гипервизор) в которой ядро до 5.8 советую Veeam Agent for Linux. Там снапшот и CBT с помощью модуля. dattobd и его форки используют несколько разных вендоров. Там есть инкрементальный бэкап, читайте как это работает тут. У других вендоров тоже, если заявлен инкрементальный или дифференциальный бэкап, то скорее всего перезачитывает он только дифференс (уточните сами).
Если система на KVM — уже было объявлено что Veeam поддержит KVM (в составе RHEL). Мне тут подсказывают что CBT там есть, так что должны быть нормальные инкременты.
Довольно популярная точка зрения. Я же просил " Комментарии на тему «А я вот логи базы экспортирую и с помощью rsync тащу файлики» тоже не интересны, так как я рассматриваю резервную копию всей системы целиком, а не какую-то её часть."
Резервная копия всей системы целиком позволяет сделать восстановление в один клик. Когда приходим момент «Х» и «криптодемон» пожирает инфраструктуру нет времени на разворачивание ОС, наката конфигов из git, и восстановление базы.
Нужна кнопка «Сделать хорошо», а точнее откатить нужные машины или даже всю инфраструктуру на нужную дату. Ключевой параметр для бизнеса — время восстановления. Этот параметр мы стараемся минимизировать.
Да. Но мы не можем держать файловую систему замороженной пока идёт резервное копирование. Даже в процессе резервного копирования сервер остаётся рабочим и выполняет свои функции. А для некоторых систем резервное копирование может выполняться сутки. Мы пользуемся «заморозкой» на время снятия снапшота. Когда снапшот снят — файловая система «оттаивает» и живёт своей жизнью, а снапшот своей.
Всё так, файловая система действительно журналируемая и fsfreeze даёт консистентное состояние, но только в том случае если после fsfreeze не поступают никакие запросы на запись.
Если прочитать метаданные в начале тома, а через пять минут дочитать том до конца по живой машине — то получится фарш. И БД превратиться в тыкву. В общем, без снапшота можно делать резервную копию только неизменяемых данных.
«Вы, наверное, хотели спросить, как делать бэкап для софта, который в случае отключения питания имеет данные в разваленном состоянии. Видимо, никак, потому что софт кривой.» — нет, нам не интересен кривой софт. Нас обычно интересуют данные на файловой системе и базы данных популярных СУБД.
Я, конечно, проверил своё решение с помощью perf. Я увидел цифры порядка десятой доли процента.
Чтобы обсуждать это предметно я предлагаю сделать эксперимент. Собрать информацию о производительности на ядре без патча. Потом собрать ядро по тому-же config-у, добавив изменения в ядро, повторить эксперимент. Третий эксперимент — уже с загруженным модулем gbdevflt и добавленным правилом.
Уверен, это будет интересный эксперимент полезный всем, если сделать его чисто.
" Не понятна позиция разработчиков ядра. :(" Дело в том что не так то просто осознать проблему. Всё работает, идёт битва на скорость на NVMe. А тут приходит какой-то новый чел и предлагает какие-то невнятные патчи. А на фоне скандала с Массачусецским Универом, вообще три раза подумаешь прежде чем что-то читать от непроверенного человека. Так что я их уже начинаю понимать. То что они делают это круто, но я продолжу свои попытке сделать ядро ещё лучше.
«Апстрим не достаточно хорошо написал код для решения ваших бизнес-задач. Да, бывает. Метод исправления? Напишите свой!»
В принципе да. Написать можно всё что угодно. Но мало написать свой out-of-tree модуль. Чтобы решение работало гарантированно везде — нужно чтобы оно было в upstream. А чтобы добавить что-то в upstream недостаточно просто написать своё.
«А вот у меня другая область видения: вот я собрал рейд из блочных рам-дисков. Он должен уметь делать снапшоты? » — я не вижу в этом проблемы. при подключении фильтра не обязательно просаживать performance. Хотя конечно он просядет во время резервного копирования. И потом, никто не заставляет вас подключать фильтр на ваш nvme. Кому надо — тот подключит. Но мне нужна возможность подключения. Для этого я добавляю проверку, что список фильтров пуст, защищённый percpu_rw_semaphore.
"Вследствие особенностей архитектуры на Эльбрус не рекомендуется использовать исключения. " — а в чём там соль, поясните пожалуйста, если можно (NDA всё таки). Это особенность VLIW архитектуры? Особенность конвейеров? И ещё вопрос, а решения на архитектуре sparc рассматривали?
Тут вопрос что кому нужно — тот в то и вкладывает.
Всё же несморя на значительные усилия со стороны многих разработчиков, Linux все-же пока не является основной игровой платформой. Поэтому поддержка дров для видео под линукс даже у ведущих в этой отрасли компаний ведётся по остаточному принципу. Работает, и хорошо.
Рост Linux сейчас в остновном в облаках, в контейнерах, в телефонах, во встраиваемой технике, в области виртуализации.
Вот если продажи nvidea будут падать из-за того что их ПО плохо работает на популярной игровой платформе — сразу всё появится с блек-джеком и прочими прелестями :)
Вообще в случае реального кейса собрать дамп ядра — это подвиг со стороны тех. поддержки. И даже со стороны отдела тестирования это необычная конфигурация машины. Так что часто приходится довольствоваться куском текста, который выплюнул сервак перед тем как повеситься. Так что kdump — это скорее механизм серьёзной отладки. Хотя на Red Hat и Fedora его обычно предлагают настроить при установке.
Ну и потом, это-ж "… для самых маленьких". Вообще, я бы и сам удовольствием почитал статью типа «Linux kernel development: отладка по взрослому». С perf-ом, KEDR-ом, удалённой отладкой по сети и прочее. Идею статьи дарю! Если кто реализует — киньте мне в личку :).
Есть в ядре директория scripts, так вот там обильно посыпано перловкой, но и python и bash есть. Меня впечатлила тула checkpatch, которая орфографию тоже проверят и не только.
WARNING: Possible repeated word: 'to'
#5626: FILE: drivers/block/blk-snap/snapimage.c:162:
+ pr_err("Unable to to close snapshot image: private data is not initialized\n");
Так что можно многому поучиться.
Есть мнение, что модули для ядра можно писать на rust.
По поводу «супер гуру» — «не боги горшки обжигают», но уровень вхождения всё равно довольно высок.
«реально ли получать деньги за разработку и поддержку Linux?» — конечно, если вы работаете к примеру в redhat :). Остальных схем я не знаю, но мне очень интересно как расходуются средства спонсоров. Если кто знает — напишите.
«Людей в черном» — собственно да, идея именно оттуда. А квантовую физику трудом Кнута заменили. Мне как-то лет двадцать тому назад эта книга в руки попалась. Бумажная такая, пошарпанная. Почитал там про бинарный поиск на магнитной ленте. Книга меня уже тогда поразила свой древностью. Однако я уверен, что изложенные в ней алгоритмы актуальны и по сей день.
Ещё может помочь распространение обновлений не всем пользователям сразу, а поэтапно. А ещё бывает практика у опытных админов устанавливать обновления не на весь прод сразу, а после его обкатки на тестовом сервере.
Мне вообще странно читать статьи про многомиллиардные убытки от повреждения IT инфраструктуры, хотя средства резервного копирования изобретены уже давно.
Готовим RFC с описанием проблемы и вариантами решения.
Нет, конечно этот модуль фильтрации не решает проблему со снапшотами. Его назначение в другом. Он позволяет заблокировать доступ к каким-то областям диска. Например запретить на запись сектора, содержащие таблицу разделов. Или запретить доступ к разделу, за исключением какого-то процесса или модуля ядра. Это может быть очень полезно для баз данных.
Просто при добавлении такого модуля в upstream появляются и функции для подключения и отключения фильтров, а значит подключаться смогут и out-of-tree модули, так-же как это было до ядра 5.8.
Добавление модуля для создания снапшотов может быть следующим шагом. Но тут проблема в том, что в ядре уже есть dm-snap, а майнтейнеры не любят дубликатов. Я пробовал работать с Майком, майнтейнером DM, который работает в Red Hat. Скажем так, у меня не особо что получилось. Я полагаю что для Майка больше важна стабильность работы существующего кода, а не расширение его функционала, что вполне понятно.
Поэтому, чтобы «не уйти в закат» прям сразу, мне видится задача: поднять актуальность проблемы в глазах майнтейнеров и всего сообщества пользователей Linux. Если будут положительные отзывы о патче со стороны разных людей (разных компаний), и они подтвердят необходимость такого фильтра в их работе — то шанс попасть в ядро резко возрастает. Нужно изметить статус проблемы от «патч какого-то выскочки» в «реально нужная фича».
Я готовлю RFC, чтобы обсудить это в upstream перед запуском самого патча. Есть ещё вариант написать статью в lwn. Но для начала решил сделать статью для Хабра.
Вся статья ради этого предложения:
Так что дочитывать необязательно, можно сразу смотреть код. Найдёте баг — заводите issue, ну или сразу pull request.
В статье я старался в простой и доступной большинству форме обозначить проблему, которую я пытаюсь решить. Может кто-то тоже столкнулся с этой проблемой и ищет решение. Могли бы объединить усилия.
Шутки про сисадмина — чтобы читалось легче и создавало позитивный эмоциональный фон. Возможно, вы не поняли шутки про разные шляпы и шапочки? Это нормально.
— извините, даже не смотрю уже лет пятнадцать. Не смешно.
Если система на KVM — уже было объявлено что Veeam поддержит KVM (в составе RHEL). Мне тут подсказывают что CBT там есть, так что должны быть нормальные инкременты.
Резервная копия всей системы целиком позволяет сделать восстановление в один клик. Когда приходим момент «Х» и «криптодемон» пожирает инфраструктуру нет времени на разворачивание ОС, наката конфигов из git, и восстановление базы.
Нужна кнопка «Сделать хорошо», а точнее откатить нужные машины или даже всю инфраструктуру на нужную дату. Ключевой параметр для бизнеса — время восстановления. Этот параметр мы стараемся минимизировать.
Если прочитать метаданные в начале тома, а через пять минут дочитать том до конца по живой машине — то получится фарш. И БД превратиться в тыкву. В общем, без снапшота можно делать резервную копию только неизменяемых данных.
«Вы, наверное, хотели спросить, как делать бэкап для софта, который в случае отключения питания имеет данные в разваленном состоянии. Видимо, никак, потому что софт кривой.» — нет, нам не интересен кривой софт. Нас обычно интересуют данные на файловой системе и базы данных популярных СУБД.
Чтобы обсуждать это предметно я предлагаю сделать эксперимент. Собрать информацию о производительности на ядре без патча. Потом собрать ядро по тому-же config-у, добавив изменения в ядро, повторить эксперимент. Третий эксперимент — уже с загруженным модулем gbdevflt и добавленным правилом.
Уверен, это будет интересный эксперимент полезный всем, если сделать его чисто.
2. свободного места для diff area нет.
3. нет change-tracking-а.
В принципе да. Написать можно всё что угодно. Но мало написать свой out-of-tree модуль. Чтобы решение работало гарантированно везде — нужно чтобы оно было в upstream. А чтобы добавить что-то в upstream недостаточно просто написать своё.
«А вот у меня другая область видения: вот я собрал рейд из блочных рам-дисков. Он должен уметь делать снапшоты? » — я не вижу в этом проблемы. при подключении фильтра не обязательно просаживать performance. Хотя конечно он просядет во время резервного копирования. И потом, никто не заставляет вас подключать фильтр на ваш nvme. Кому надо — тот подключит. Но мне нужна возможность подключения. Для этого я добавляю проверку, что список фильтров пуст, защищённый percpu_rw_semaphore.
"Вследствие особенностей архитектуры на Эльбрус не рекомендуется использовать исключения. " — а в чём там соль, поясните пожалуйста, если можно (NDA всё таки). Это особенность VLIW архитектуры? Особенность конвейеров? И ещё вопрос, а решения на архитектуре sparc рассматривали?
Всё же несморя на значительные усилия со стороны многих разработчиков, Linux все-же пока не является основной игровой платформой. Поэтому поддержка дров для видео под линукс даже у ведущих в этой отрасли компаний ведётся по остаточному принципу. Работает, и хорошо.
Рост Linux сейчас в остновном в облаках, в контейнерах, в телефонах, во встраиваемой технике, в области виртуализации.
Вот если продажи nvidea будут падать из-за того что их ПО плохо работает на популярной игровой платформе — сразу всё появится с блек-джеком и прочими прелестями :)
Ну и потом, это-ж "… для самых маленьких". Вообще, я бы и сам удовольствием почитал статью типа «Linux kernel development: отладка по взрослому». С perf-ом, KEDR-ом, удалённой отладкой по сети и прочее. Идею статьи дарю! Если кто реализует — киньте мне в личку :).
WARNING: Possible repeated word: 'to'#5626: FILE: drivers/block/blk-snap/snapimage.c:162:
+ pr_err("Unable to to close snapshot image: private data is not initialized\n");
Так что можно многому поучиться.
Есть мнение, что модули для ядра можно писать на rust.
По поводу «супер гуру» — «не боги горшки обжигают», но уровень вхождения всё равно довольно высок.
«реально ли получать деньги за разработку и поддержку Linux?» — конечно, если вы работаете к примеру в redhat :). Остальных схем я не знаю, но мне очень интересно как расходуются средства спонсоров. Если кто знает — напишите.