Лига Сисадминов

В мире энтерпрайза концепция «совместной работы» существовала с момента появления проектов, которые один человек не может сделать физически. То есть где-то с начала 20 века.
В мире электроники, малого и среднего бизнеса можно отметить:
IBM AN/FSQ-7 Combat Direction Central (1955 год) и Semi-Automated Ground Environment (SAGE) (1958 год), из которых потом вырос интернет.
Apache Subversion (svn) – 2000 год
FreeBSD jail – 2000 год
Git – 2005 год.
Microsoft Team Foundation Server (TFS) и Visual Studio Team System (VSTS) – 2005 год.

К 2020 году профессия сформировалась, в том числе в РФ. Сформировала мем про заработок в 300кк/наносек, своих мемных персонажей (например, Хрыча), итд.
И .. нельзя сказать, что умерла. Скорее, участники разбились на две фракции:
- дешевая, где кандидатов (работников) много, и они за пределами своей RUN команды, не могут почти ничего
- дорогая, активно разбежавшаяся в (на) Кипр, Сербию, Черногорию, Германию, Ирландию, итд. Частично Тбилиси, Кутаиси. Часть осталась в РФ.
Очень было смешно, когда Экспресс 42 в итоге слился с Флантом. То есть, еще в 2023 году рынок галерной разработки \ девопс в РФ схлопнулся настолько, что двум командам было не выжить.

Середины «качества и оклада» нет, середина не нужна.

По моему опыту, из «низшей» лиги в «высшую» переходит 2 кандидата из 10 «девопсов».
Если брать совокупный отсев, то :
из 1000 человек – 900 могут пользоваться «техникой».  Назовем их «Сотрудники»
из 1000 человек – 200 могут быть «ИТ шниками». Назовем их «помошники сисадмина».
из 200 «ИТ шников» 20 могут стать «системными администраторами уровня мидл», или девопсами «мидл, которого нельзя пускать к проду». Но из них получаются хорошие ИТ менеджеры, если прокачан скилл «красноречие» и «убеждение».
Из 20 сотрудников «уровня мидл» можно получить 2 сотрудников: одного технического сеньора (лида) и одного лида с функциями менеджера.  
Проблема, и очень большая, в том, что на уровне «мидл» и «сеньор» приходится качать не только знание «ключей к командам, записанных в руководстве», но и организацию труда. И постоянно читать «что там нового».

И на этом месте в РФ, и не только в РФ, происходит и кассовый, и технический разрыв.

В чем это выражается?

Рассмотрим жизненный цикл двух сотрудников, Васи и Пети. Оба примерно одной (отсутствующей) квалификации в начале жизненного цикла. Оба идут на работу на «первую линию», обоим везет – у них в команде есть вменяемый ментор, который заинтересован в быстром развитии персонала, чтобы свалить на них побольше работы, а самому учиться или чилить. Со стороны всегда выглядит как «чилить».

Вася. Быстро учит базу, основные команды, основные ситуации, и дальше не особо учится «оплачиваемым навыкам». Работает по своему графику 8/5. Потом, чтобы заработать «побольше, как ему кажется» уходит на работу в сменах, сутки – двое, и считает, что чему-то учится. В пределах своей работы – уважаемый специалист.

Петя. Быстро учит базу, основные команды, основные ситуации, и дальше пытается учиться. И встречается с проблемой: для смены работы или спрашивают существенно больше, или предлагают больше работать «в часах».
И тут скрывается ловушка: кажется, что спрашивают столько, что выучить нельзя, и может только повезти. Это не так, выучить то, что спрашивают на интервью, можно. НО. Только если ты с этим каждый день работал самостоятельно. Чтобы работать самостоятельно, нужно чтобы тебя взяли на работу и научили, а чтобы взяли на работу, надо пройти интервью. Замкнутый круг, с первого взгляда. Два стула из классической загадки. И та самая вилка на втором интервью.  

Важно понимать, что оба варианта развития важны и нужны. Не всем хочется и можется учиться, люди не равны, и играть в рулетку иногда страшно, иногда невозможно. Ничего плохого в этом нет, Бесплатных завтраков не бывает, There ain't no such thing as a free lunch, TANSTAAFL

Поэтому для развития нужно:

Первому уровню, до docker compose start включительно, можно и нужно научиться самостоятельно

Для развития в направлении devops/ML, нужны:
- Загранпаспорт
- Работающие социальные скиллы
- Разговорный английский на 5 баллов (максимальный балл - 9.0) . Он же FCE. Он же  B2 по CEFR.
- Минимум одна поездка на Кипр, туристом.
- Минимум одна поездка в Таиланд, точнее в Паттайю, точнее Walking street, туристом
- Водительские права категорий A, B. Обе категории нужны.
- Чтение тематических каналов и чатов
- Пет проект «как у больших, только на k3s, proxmox, и домашней видеокарте».  Со всеми свистелками и перделками – графаня, графаня локи, эластик, итд.

Дело не в том, что «самому не выучиться».
Самому выучиться, но текущее состояние рынка труда таково, что нужны социальные связи, и постоянная демонстрация, что ты не мудак.
Дело не в том, что «чего я там не видел в Паттайе», дело в том, что «видел сам». Другая ментальность, другая реальность, расширение кругозора, итд. И, говоря про Паттайю, повышение наблюдательности и, особенно после местных шоу, снятие сакральных скреп, и отрешение от духовности и навязанной идентичности, а местами и от идемпотентности. И, как следствие, улучшение характера и прекрасный аппетит.

Английский в этом списке нужен затем, что актуальной литературы на русском по теме не было, нет, и не будет. «Литература» есть. Актуальной нет.

Где тут кассовый разрыв ? Везде. Бизнес хочет работника "чтобы все умел, и недорого", и в то же время другой бизнес предлагает в 2 раза больше, за тот же пакет знаний. НО, поскольку у второго бизнеса отвратительные HR, то ты про такую вакансию узнаешь, только будучи "в общем коллективе".

Важное отличие «рассказов от HR» и «рассказов от преподавателей в РФ» от реальности находится именно тут.

В теории считается, что если ты хороший (очень хороший) специалист, и твои технические навыки не вызывают никаких сомнений, то тебе не нужны социальные скиллы. Минимум два популярных сериала (Компьютерщики и Теория большого взрыва) построены вокруг «персонажей с отсутствующими социальными навыками».
В реальности на любом уровне, и чем выше уровень, тем чаще, тебе приходится больше заниматься людьми, чем техникой.
Следующая часть как раз будет «Про прибыль, и как же они не понимают».

Подводя итог

Лет 15-20 назад я думал, что существует 5-10 технических направлений, в которых достаточно «научиться» и дальше «жизнь удалась». Наверное, 20 лет назад, в 2006 году, так и было.
И в школе, и в институте, учат именно так – что «успех» это «демонстрация технических знаний» экзаменатору.
В школе и институте это именно так, критерий успеха – сданный экзамен.

В жизни критерии и метода чуть иные.

При этом нужность технической базы никто не отрицает, но крайне важно понимать, что лозунг «учись учиться самостоятельно», это не просто лозунг. Вкатиться просто. Для переката выше нужно уметь, хотя бы с 5-10 раза, не только составить собственный учебный план, не только иметь силу воли и следовать ему, но и решать вопросы не только техническим путем.

Читать эти 6 книг нужно именно в таком порядке, по мере выхода книг.
Остальные читать в любом порядке.

1 Фредерик Уинслоу Тейлор . Принципы научного менеджмента
Удивительно, но по запросу «тейлор научная организация труда читать онлайн» книга будет не второй ссылкой, а четвертой.

2 «Мифический человеко-месяц, или Как создаются программные системы» (англ. The Mythical Man-Month: Essays on Software Engineering)

https://ru.wikipedia.org/wiki/Мифический_человеко-месяц

3 Deadline. Роман об управлении проектами

4 Проект Феникс. Роман о том как DEVOPS меняет бизнес к лучшему

5 Весь цикл «Рождение советской ПРО»: https://topwar.ru/user/Sperry/

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

6 Билл Гейтс. Бизнес со скоростью мысли

PS. Про ML как отдельный процесс так ничего и не написал. Видимо, у меня есть представление, что devops занимаются и AI, и ML. Хотя правильнее было бы поговорить про команду по внедрению изменений, но извините, так вышло.

Разработчик под ником akshay | Contour (X/Twitter) демонстрирует созданный им экспериментальный браузерный плагин, который позволяет рисовать схемы прямо поверх своего изображения во время видеозвонков.

Плагин создавался как стандартное расширение для браузеров на базе движка Chromium.

Скачать расширение можно тут: A.I.R. draw — draw on your video call with your hands

Для того, чтобы понимать, куда расти, нужно иметь какую-то карту.
Было бы неплохо понимать, какие боссы есть на карте, в каких локациях.
И где самый страшные чародейки, то есть HR (очевидно, на Скеллиге, под скалой).
Раз уж речь про ИТ, то пройду сначала по жизненному циклу любой программы.
Чтобы программа появилась, нужен запрос. Бизнеса, преподавателя, мироздания, задней чакры – не важно. Есть какой-то запрос, или задача, ее решает какая-то программа.
Говоря про бизнес, в нем ИТ, то программа, или помогает заработать еще больше денег, или помогает сэкономить деньги. Есть исключение – SAP . Это программа, которая позволяет хоть как-то управлять организацией, и хоть немного снизить уровень вранья в консолидированной отчетности. Появилась это программа в 1972 году в Германии, точнее в Федеративной Республике Германия (Bundesrepublik Deutschland), и называлась Systemanalyse und Programmentwicklung. И то, не всегда помогает, про это ниже.

После того, как бизнес сформулировал «чего он хочет», в дело вступают аналитики, разработчики, тестировщики, дизайнеры, и масса других людей, полезных и не очень. SLDPC, PMbook, ценности, вот это все.
Не очень давно, лет 20 назад, в этом процессе сформировался процесс передачи продукта между разработкой, development (dev) и эксплуатацией (operation, ops). Dev/ops. Спустя 20 лет инженером devops, или просто devops, называют кого угодно. Как и системным администратором, или сетевым инженером. В мире тоже наблюдается бардак.
Я уже не первый год считаю, что бардак сначала формируется "на западе", а спустя 3-5 лет обнаруживается в РФ.
В мире ops полно профессий «вроде в ИТ, но не про настройки железа и ОС». Это и DBA, и data инженеры, и масса «берем любую задачу, вместо инженер пишем OPS» - dataops, mlops,scratchballsops, etc. Единого классификатора нет, но есть общее поле «кто примерно чем занимается».
Рядом с «чистым ИТ» сейчас идет и маркетинг – где ИТ выступает как еще один инструмент продаж. Или как механизм формирования общественного мнения, как «агентство интернет исследований». Или как «обидчивые модераторы из Минцифры на филиале сделано у нас, он же Хабр,» или как «рекламные агенты минцифры, побежавшие рекламировать филиал Минцифры в виде Хабра, как стоящую внимания площадку».
Цифры реального падения посещаемости, а не бот-статистике:
после передачи модерации хабра в минцифру,
после начала ухода рекламодателей на Пикабу,
говорят сами за себя.

Однако, не про них.

Важно понимать, что и разработчики, и девопс, и QA, нужны в относительно небольших количествах. Далеко не везде есть хоть какая-то разработка.
Важно понимать и то, что инфраструктура как код существует со времен существования инфраструктуры. Только в 1950 году это было «программирование инфраструктуры путем втыкания кабелей в схему», в 1970 это были стопки перфокарт, сейчас это код, но на чем-то человекочитаемом.
Программировать «хотя бы на ямле» нужно уметь всем, кто вкатывается. Вне зависимости от отрасли. Даже если это уровень полного дна, и неумения написать сортировку пузырьком.

Отдельным блоком стоит упомянуть разработку и программирование микроконтроллеров, промышленную автоматику,  рисование всяких схем нарезки, управления разными солидолами и прочими автоматизированными напильниками, в том числе и хорошо, и плохо шлюховальными. Тут я советов не дам, за советами вы знаете куда идти – сразу за упавшим краном налево. Тоже про ИТ, тоже про код, только в результате кода получается железка нужной формы и шероховатости.
Еще сотню направлений я забыл упомянуть. Тут и торговля страхом, она же «имитация безопасности», и торговля кнутом без пряника, и не тем Кнутом, который не в банде четырех, а тем, который считает человеко-часы и мышкопробег. И тем, который отслеживает обновление вашего резюме, или «анонимно» считает уровень вашей удовлетворенности.

Куда расти

Как я пишу из текста в текст «ИТ» не приносит прибыли, это расходное подразделение по учету.
Однако, даже маркетингу нужно что-то продавать. Продавать можно продукты и услуги.
Продукт кто-то должен написать, собрать, протестировать, доставить. Это не обязательно приносит прибыль, фирмы разработки регулярно разоряются и закрываются, но все же в фирме по разработке сотрудники являются средством производства.
То же самое могло бы касаться услуг, если бы на российском (да и мировом) рынке падение качества услуг что-то стоило руководству. Не часов на совещаниях и оправданиях за провалы планов, а чего-то денежного. И то, на дивном западе строят пирамиды побольше, чем МММ. Желающие могут почитать про жизнь фирм Arthur Andersen , Purdue Pharma, McDonnell Douglas, или пролистать Якокку (Карьера менеджера).
Поэтому «в целом» разработка с точки зрения возможного роста лучше эксплуатации, но и в разработке встречается удивительно конченые, не понятно как живущие, галеры.
В эксплуатации ситуация, что на российском, что на мировом рынке, плавно становится хуже с точки зрения денег. Причины:
- Облака. Из эксплуатации сразу выпадает весь блок «по железу», зато вместо него появляется блок «сервисы» и «сети». Облако может обходиться как «в два раза дороже наземного варианта постройки» - если считать эксплуатацию в стабильной среде в 5 летний срок, так и «в два раза дешевле наземного варианта» - потому что кредиты дороги, место дорого, лицензии дорого, люди .. и так далее.
- Скорости. 15 лет назад для приемлемого функционирования системы чуть сложнее калькулятора уже надо было покупать свое «тяжелое» железо, свои СХД.
Сейчас? Микрософт и Амазон предлагают IBM i как облачные сервисы, мигрируйте сколько хотите.
Сейчас? Просто покупаете «железо предпоследнего поколения» и получаете власть, которая и не снилась вашему отцу.
- Сложность. Базовые сервисы записаны как код, описаны в плейбуках, никаких тайных знаний, передаваемых внутри Великой Лажи. Не хватает «скорости» - просто докупи «что-то как сервис». Причем, как сервис наполовину из вчерашних техников, но прошедших внутренние экспресс курсы, и консультирующихся с внутренними ИИ. Внутрение ИИ существуют в разного рода форматах с середины 2000 (если не раньше), сейчас с разметкой получше стало.

С разработкой, конечно, тоже все не так хорошо. Скорее, «тоже нехорошо» - основной софт написан лет 20-30 назад, а добавляемые функции нужны хорошо если 1% потребителей. Но, раз они нужны, и именно тем потребителям, что приносят деньги, то, конечно, мировые корпорации будут ориентироваться на топ 1%, может топ 10%, покупателей.
Не будет SAP ориентироваться на ларек с шавермой, даже скидку не сделает.

Каких боссов ожидать

С боссами тоже очень интересная история, идет прямо сейчас. Если говорить про Европу и США, то эджизм, или, по простому, «старикам тут не место», No Country for Old Men, был всегда. Но, профсоюзы (в США) и социалисты (в Европе) сделали старость чуть получше, и до какого-то уровня сложные профессиональные навыки еще находили спрос на рынке труда.
Сейчас мировая экономика, скорее, в вялотекущем кризисе. Обсуждение ее причин выходит за рамки статьи. Поэтому оплачиваемый спрос на любой труд здорово упал, где-то больше, где-то меньше. Где-то рабочие бастуют против внедрения роботов, где-то уже нет.
Разговоры, что "нужны специалисты по коболу" есть, зарплат и рабочих мест нет.

Но эджизм проявляется очень по разному, и про это будет ниже.

Босс самый простой, HR.
При приеме на работу вы так или иначе (есть варианты обхода) будете проходить HR.
Новички вкатуны понаивнее делают классическую ошибку (и в отношениях тоже), пытаются «впечатлить HR» и показать, что они хорошие мальчики. Это ошибка в стиле «казаться, но не быть», и «пытаться разжалобить робота». Почему? Потому что сейчас примерно (оценочно) 90% HR занимаются чем угодно, кроме анализа и найма. У них нет ни четкого заказа «от бизнеса», ни понимания «кого ищут», ничего. Поэтому отсев на этой стадии можно считать случайным – на одно и то же (скопированное друг у друга) описание вакансии отсев может идти совершенно вне профессиональных и личных навыков. Фактически, иногда на уровне «нравится \ не нравится». К примеру, на одном из предыдущих мест работы HR оценивала кандидатов примерно на уровне «хочу ли я с ним переспать». Профессиональные навыки оценивались «никак», отсев был примерно 90-95%%. Реальный контроль за отсевом отсутствовал. И это еще во времена существенного спроса на кадры.
Сейчас платежеспособного спроса на «кадры вообще» почти нет (ни в Европе и США, ни в РФ), есть вялый перебор «нуууу может быть». Стабильность перед падением. Или стагнация. Или нет. Разговоров много, но как-то давно не было кризиса уровня 1984 (ипотечный), 2000 (доткомы) 2008 (ипотека).

Как проходить этот уровень.
Никак, не надо его проходить. Если вы не можете в эту игру выиграть, не  надо в нее играть. Не играйте в казино или в наперстки, если вам не нравится сама игра.
Наиболее рабочий путь найма – через широкую социальную профессиональную сеть. Если вы «на виду», то спрашивайте знакомых, что у них как. Рано или поздно вас попробуют подтянуть куда-то.
Потому что сотрудник- социофобушек, думающий что он что-то знает – не нужен. Времена поменялись.

Босс самый неприятный, «дедушка токсик».
Встречается куда чаще, чем я думал. Дедушка, который угнетает, только потому, что угнетали его. Или до сих пор угнетают. И проблема не в том, что он угнетает. Проблема в том, что он угнетает без обратной связи. Например, дает какую-то задачу, которую не может решить сам (это нормально), но, когда ты к нему приходишь, то вместо «давай посидим подумаем, что тут такое» получаешь «да это элементарно» и «иди книжки \ интернет \ справочник читай». В современных условиях и с современной базой, не факт, что ты сможешь найти то, о чем речь.
Я то не всегда могу найти, и вынужден писать статьи «так, что тут такое».
Отвратительно, конечно, когда что-то ищешь спустя пару лет, и находишь 3 статьи одна из которых твоя, а вторую писал вон тот Вася, которого ты и так знаешь, а третья в блоге разработчиков, и ты ее тоже уже читал.
Я много раз сталкивался с таким. Этот вариант может принимать разные формы. 
Относительно приемлемую, где дедушка знает, что решение есть, потому что видел это решение и его применял, и может что-то вспомнить.
Форму понеприятнее, где дедушка думает, что помнит, решение есть. Хотя это уже склероз и маразм, готового, и не готового, решения нет.
И самую неприятную форму, когда ты делаешь решение, пусть даже это скрипт на коленке. И вместо того, чтобы посмотреть решение, дед говорит, что решение без гуя ему не нравится. Нужно чтобы решение было написано кем-то еще, и было с гуем. Все. Тупик.
Бывает в формате «супербосс», когда коллектив долго (пару лет) пытается, под таким руководством, внедрить систему «для делания сразу везде хорошо». Потому что 30-40 лет назад подход «водопад», с его «долго планируем, долго делаем» был нормальным. Вместо того, чтобы сделать концепт «сделаем хорошо вот так быстро» и посмотреть. По схеме «Малая гипотеза – быстрая проверка – микросервис – результат», оно же «что-то почти Agile».

Что делать, как проходить.
В таких случаях всегда люди:
или увольняются, потому что квалификация по «поиску приятных решений» не равна квалификации, оплачиваемой на рынке,
или строят параллельный набор своих костылей и микросервисов, который работает, пока дедушка даже не имитирует, а пытается построить систему «как он ее видит».
или спрашивают советов в интернете.

Босс «крах культуры без вины и концепции вин-вин».
Культура «не обвинять сотрудника» - это отдельное явление в как-бы-культуре, стоящее отдельного описания. Уже умерло, не успев родиться.
Крах концепции вин-вин – это явление из теории игр, когда конфликтная ситуация разрешается к взаимной прибыли.
Сейчас «Метод принципиальных переговоров» , именно так это называется, слишком часто просто не работает. Потому что никто не собирается вести переговоры. Что ж.

На уровнях выше будут совсем другие боссы, например квест "согласование изменений бюджета".

Литература дополненная

https://en.wikipedia.org/wiki/Just_culture

https://www.mindtools.com/auit7t0/blame-culture-vs-no-blame-culture/

Читать эти 6 книг нужно именно в таком порядке, по мере выхода книг.
Остальные читать в любом порядке.

1 Фредерик Уинслоу Тейлор . Принципы научного менеджмента
Удивительно, но по запросу «тейлор научная организация труда читать онлайн» книга будет не второй ссылкой, а четвертой.

2 «Мифический человеко-месяц, или Как создаются программные системы» (англ. The Mythical Man-Month: Essays on Software Engineering)

https://ru.wikipedia.org/wiki/Мифический_человеко-месяц

3 Deadline. Роман об управлении проектами

4 Проект Феникс. Роман о том как DEVOPS меняет бизнес к лучшему

5 Весь цикл «Рождение советской ПРО»: https://topwar.ru/user/Sperry/

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

6 Билл Гейтс. Бизнес со скоростью мысли

# Добавляем репозиторий apt.bcachefs.org (unstable / bcachefs-tools-release) и затем ставим всю обвязку

sudo apt install bcachefs-tools bcachefs-kernel-dkms fio btrfs-progs

По итогу получаем собранный модуль (bcachefs.ko.zst версии 1.38.6), и dmesg ожидаемо сыплющий ворнингами про tainting kernel и verification failed. Ну это просто надо иметь ввиду - теперь вы живете на внешнем модуле, и при каждом обновлении ядра нужно будет пристально следить за DKMS.

bcachefs: loading out-of-tree module taints kernel

bcachefs: module verification failed: signature and/or required key missing - tainting kernel

bcachefs: filldir64 fastpath disabled: struct layout unverified for this kernel

2. Базовый single-disk сценарий

Первый тест был максимально тупой и прямолинейный:

1. Создать ФС на одном диске.

2. Смонтировать.

3. Записать файл 1 GiB и 5000 мелких файлов.

4. Запустить usage/scrub.

5. Размонтировать и выполнить offline check.

Для Bcachefs:

sudo bcachefs format -f -L bcf_single /dev/sdb

sudo mount -t bcachefs -o noatime /dev/sdb /mnt/bcf

sudo bcachefs fs usage -h -a /mnt/bcf

sudo bcachefs scrub /mnt/bcf

sudo bcachefs fsck -n -f /dev/sdb

Для Btrfs:

sudo mkfs.btrfs -f -L btr_single /dev/sdc

sudo mount -t btrfs -o noatime /dev/sdc /mnt/btr

sudo btrfs filesystem usage -T /mnt/btr

sudo btrfs scrub start -B /mnt/btr

sudo btrfs check --readonly /dev/sdc

На этом этапе всё скучно, единственная практическая ценность тут - набор команд для создания ФС, может кому пригодится как шпаргалка.

Можно еще отдельно сказать про команды Bcachefs. Они непривычны, но в целом на удивление логичны: вместо mkfs.bcachefs используется bcachefs format, диагностика идёт через bcachefs fs usage, проверка через bcachefs fsck.

3. Сжатие

Для проверки сжатия использовал простой набор:

1. zero-512m.bin, 512 MiB нулей.

2. random-256m.bin, 256 MiB случайных данных.

Bcachefs создавалась сразу с zstd:

sudo bcachefs format -f -L bcf_zstd --compression=zstd /dev/sdb

Btrfs монтировалась с compress=zstd:

sudo mount -t btrfs -o noatime,compress=zstd /dev/sdc /mnt/btr

У Bcachefs понравилась отдельная секция в fs usage:

Итоговое использование места:

Bcachefs - около 283 MiB

Btrfs - около 274 MiB

Обе ФС отработали отлично (нули сжали, рандом пропустили). Разница в несколько мегабайт тут не имеет особого смысла.

Из интересного - у Bcachefs утилита fs usage выдает шикарную и очень наглядную статистику по сжатым/несжимаемым данным прямо в консоль.

4. Снапшоты

Снапшоты проверял простым бытовым сценарием:

1. Создать subvolume.

2. Записать state.txt со значением original.

3. Создать read-only snapshot.

4. В живом subvolume поменять файл на changed.

5. Прочитать файл из snapshot.

Bcachefs:

bcachefs subvolume create /mnt/bcf/subv

bcachefs subvolume snapshot -r /mnt/bcf/subv /mnt/bcf/snap1

Btrfs:

btrfs subvolume create /mnt/btr/subv

btrfs subvolume snapshot -r /mnt/btr/subv /mnt/btr/snap1

Результат у обеих ФС одинаковый:

live=changed

snapshot=original

Здесь ноль сюрпризов. Снапшоты работают так, как от CoW-ФС и ожидаешь.

5. Производительность fio и мелкие файлы

Теперь к цифрам. Ещё раз: это синтетические тесты внутри одного сомнительного стенда.

Параметры fio:

single disk

без сжатия

sequential read/write: bs=1M, size=2G

random write: bs=4k, numjobs=4, iodepth=16, runtime=30

Первые три строки ниже - это fio. Создание и удаление 10000 мелких файлов замерялись отдельно обычным shell-сценарием: создание дерева файлов и последующий rm -rf этого дерева.

Результаты:

На этом стенде Bcachefs заметно быстрее на последовательной записи, random write 4K и создании мелких файлов. Btrfs, наоборот, быстрее на последовательном чтении и чуть быстрее удаляет дерево мелких файлов.

Само собой всё это автоматически не приводит нас к выводу, что Bcachefs быстрее Btrfs. Всё таки подложка в виде Proxmox/ZFS может сильно влиять на такие цифры. Но как лабораторный результат - как минимум любопытно.

Отдельный нюанс: во время нагрузки у Bcachefs в dmesg появилась строка:

bcachefs (sdb): bch2_journal_flush_seq stuck? Waited 10s for seq 32

После этого ФС нормально размонтировалась и прошла проверки. Но при эксплуатации это сообщение нельзя просто игнорировать. Его стоит отдельно разбирать при повторных тестах.

6. Multi-device

Одна из причин вообще смотреть на Bcachefs - обещание функциональности уровня современных CoW-ФС с более гибкой моделью устройств.

Bcachefs с двумя копиями данных и метаданных создаётся так:

bcachefs format -f -L bcf_raid1 --replicas=2 /dev/sdb /dev/sdc

После записи 512 MiB полезной нагрузки bcachefs fs usage показал ожидаемую репликацию:

Btrfs RAID1 создавался привычно:

mkfs.btrfs -f -d raid1 -m raid1 -L btr_raid1 /dev/sdb /dev/sdc

У него всё ожидаемо отображается через Data ratio: 2.00 и Metadata ratio: 2.00.

Нюанс в терминологии: у Bcachefs модель --replicas=2 читается проще. Мы описываем желаемое количество копий, а не выбираем отдельные RAID-профили для data и metadata. Для админа это вполне приятная деталь.

7. Потеря диска на живую

Ну и само собой важная часть для любой multi-device ФС нифига не красивая таблица fio, а поведение при отказе.

Сначала пробовал имитировать отказ изнутри гостевой ОС через /sys/block/*/device/delete и device/state=offline. В этой ВМ метод оказался ненадёжным: устройство либо оставалось видимым, либо состояние быстро возвращалось в running.

Поэтому финальный тест делал через QMP hot-unplug на уровне Proxmox/QEMU. Постоянную конфигурацию ВМ не менял, удалял только live-устройство.

Bcachefs

Сценарий:

1. Bcachefs на /dev/sdb и /dev/sdc.

2. Форматирование с --replicas=2.

3. Запись 256 MiB payload.

4. QMP device_del scsi2, то есть удаление второго диска.

5. Проверка чтения старого файла и запись нового файла.

После hot-unplug /dev/sdc исчез из lsblk. Чтение и запись продолжили работать:

/mnt/bcf/payload.bin: OK

-rw-rw-r-- 1 user user 20 ... /mnt/bcf/after-qmp-hotunplug.txt

Диагностика Bcachefs показала, что часть метаданных уже требует восстановления реплик:

В dmesg появились ожидаемые ошибки по удалённому устройству:

bcachefs: error writing btree node ... sdc io: BLK_STS_OFFLINE

bcachefs (sdc): offline from block layer

bcachefs: error writing btree node ... sdc io: BLK_STS_REMOVED

Практический вывод: ФС осталась рабочей, данные читались, новая запись прошла. При этом состояние явно деградировало и требует дальнейшего reconcile/восстановления. Собственно, именно это и хотелось увидеть от теста.

Btrfs

Для Btrfs аналогичный сценарий делал на другой паре дисков:

1. Btrfs RAID1 на /dev/sdd и /dev/sde.

2. Так же запись 256 MiB payload.

3. QMP device_del scsi4.

4. Проверка чтения и запись нового файла.

После удаления /dev/sde ФС тоже продолжила работать:

/mnt/btr/payload.bin: OK

-rw-rw-r-- 1 user user 20 ... /mnt/btr/after-qmp-hotunplug.txt

btrfs filesystem usage -T показал missing device:

WARNING: failed to get device size for /dev/sde: No such file or directory

Device missing: 20.00GiB

В dmesg появились ошибки записи на удалённое устройство:

BTRFS error (device sdd): bdev /dev/sde errs: wr 1, rd 0, flush 0, corrupt 0, gen 0

BTRFS warning (device sdd): lost super block write due to IO error on /dev/sde (-5)

BTRFS error (device sdd): error writing primary super block to device 2

В этом конкретном сценарии обе ФС повели себя адекватно: RAID1-подобная конфигурация пережила потерю одного диска на живую, данные остались читаемыми, запись продолжилась.

8. Что там по UX

Понравилось в Bcachefs:

1. bcachefs fs usage -h -a очень информативен.

2. Хорошо видно data/metadata, compression, btree и состояние устройств.

3. Модель --replicas=2 читается проще, чем отдельные профили -d raid1 -m raid1.

4. Снапшоты и subvolume-команды выглядят логично.

5. Потерю одного устройства при репликации ФС пережила.

Минусы:

1. Вместо нормальной поставки в составе ядра - поставляется как DKMS-модуль со всеми вытекающими (вообще надо было постараться настолько сильно выбесить мейнтейнеров ядра своим стилем разработки, чтоб тебя со скандалом вып*здили из mainline)

2. В dmesg был warning про bch2_journal_flush_seq stuck.

3. Сценарий возврата или замены диска после hot-unplug надо тестировать отдельно.

У Btrfs главный плюс скучный, но весомый: он давно есть в дистрибутивах, хорошо документирован, привычен и в принципе практически стабилен.

Итоги

1. Bcachefs после снятия experimental уже имеет смысл тестировать в homelab.

2. В базовых сценариях ФС отработала нормально: создание, монтирование, scrub/fsck, сжатие, снапшоты, multi-device.

3. На этом стенде Bcachefs хорошо выступила на записи и мелких файлах, но это синтетические тесты.

4. Потерю одного диска при --replicas=2 Bcachefs пережила: данные читались, запись продолжалась, диагностика показала деградацию.

Если резюмировать, то основные вопросы пока не столько к самой ФС, сколько к эксплуатационной обвязке: DKMS, обновления ядра, загрузка модуля и восстановление после отказов.

ИМХО, для лаборатории, тестового NAS, домашнего стенда и удовлетворения инженерного любопытства - да, Bcachefs уже интересно гонять. Для продакшена или единственной копии важных данных - только после собственных аварийных тестов и с нормальными бэкапами.